[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160281#comment-17160281
]
ASF subversion and git services commented on GEODE-8337:
Commit 2a3b609ceb2f9374cc847d0f367ab2d53f5392a0 in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2a3b609 ]
GEODE-8337: git mv VersionOrdinal.java->Version.java
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160278#comment-17160278
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill merged pull request #5355:
URL: https://github.com/apache/geode/pull/5355
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
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160280#comment-17160280
]
ASF subversion and git services commented on GEODE-8337:
Commit 17d6679125942f5f33ded4670dc9e0ca643e03da in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=17d6679 ]
GEODE-8337: git mv Version.java->KnownVersion.java
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160261#comment-17160261
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill edited a comment on pull request #5355:
URL: https://github.com/apache/geode/pull/5355#issuecomment-660372715
Distributed test failure is due to open, flaky
[GEODE-8191](https://issues.apache.org/jira/browse/GEODE-8191) so I'm calling
the distributed test ok ✓
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
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160260#comment-17160260
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill edited a comment on pull request #5355:
URL: https://github.com/apache/geode/pull/5355#issuecomment-660372715
Distributed test failure is due to open, flaky
[GEODE-8191](https://issues.apache.org/jira/browse/GEODE-8191) so I'm calling
that test ok ✓
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
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160259#comment-17160259
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill commented on pull request #5355:
URL: https://github.com/apache/geode/pull/5355#issuecomment-660372715
Distributed test failure is due to
[GEODE-8191](https://issues.apache.org/jira/browse/GEODE-8191) so I'm calling
that test ok ✓
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
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160246#comment-17160246
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill commented on pull request #5355:
URL: https://github.com/apache/geode/pull/5355#issuecomment-660366214
Acceptance test failed with:
```go
> Task :geode-assembly:docker
free(): invalid pointer
SIGABRT: abort
PC=0x7fb44f973e97 m=0 sigcode=18446744073709551610
signal arrived during cgo execution
goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x4afd50, 0xc420051cc0, 0xc420051ce8)
/usr/lib/go-1.8/src/runtime/cgocall.go:131 +0xe2 fp=0xc420051c90
sp=0xc420051c50
```
I'm assuming this is due to a bug in Docker or a resource issue in the CI
infrastructure. I'm re-triggering this suite…
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
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160206#comment-17160206 ] ASF subversion and git services commented on GEODE-2113: Commit 4b84af392df529a94a7d3163966d9b28ae9cf79c in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4b84af3 ] GEODE-2113: User Guide - p2p.HANDSHAKE_POOL_SIZE is obsolete, remove from docs (#5383) > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160205#comment-17160205 ] ASF GitHub Bot commented on GEODE-2113: --- davebarnes97 merged pull request #5383: URL: https://github.com/apache/geode/pull/5383 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 > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8361.
Fix Version/s: 1.14.0
Resolution: Fixed
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160172#comment-17160172
]
ASF subversion and git services commented on GEODE-8361:
Commit 11ab87fbfe1229aea47ba1cd48439157318070c9 in geode's branch
refs/heads/feature/GEODE-7665 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=11ab87f ]
GEODE-8361: Use Set instead of List to track cleared buckets (#5379)
- Refactor PartitionRegionClear to use Set instead of List
- Some other changes to remove warnings/alerts from PartitionedRegionClear and
PartitionedRegionClearMessage
Authored-by: Donal Evans
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160170#comment-17160170
]
ASF GitHub Bot commented on GEODE-8361:
---
DonalEvans merged pull request #5379:
URL: https://github.com/apache/geode/pull/5379
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
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8337:
--
Labels: pull-request-available (was: )
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160162#comment-17160162
]
ASF GitHub Bot commented on GEODE-8337:
---
Bill commented on pull request #5355:
URL: https://github.com/apache/geode/pull/5355#issuecomment-660300943
Thanks for the review @bschuchardt. I'm rewriting history on this PR now to
get it down to the minimal number of commits (2). After CI runs on that I'll
merge it!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[
https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160160#comment-17160160
]
ASF GitHub Bot commented on GEODE-8364:
---
pdxcodemonkey commented on a change in pull request #629:
URL: https://github.com/apache/geode-native/pull/629#discussion_r456634323
##
File path: cppcache/test/CacheTest.cpp
##
@@ -61,3 +62,10 @@ TEST(CacheTest, close) {
EXPECT_THROW(cache.readyForEvents(), CacheClosedException);
EXPECT_THROW(cache.rootRegions(), CacheClosedException);
}
+
+TEST(CacheTest, changeLogLevel) {
+ auto cache = CacheFactory{}.set("log-level", "info").create();
+ ASSERT_EQ(cache.getLogLevel(), LogLevel::Info);
Review comment:
Exactly - I was thinking about this earlier this morning. We can still
get into the kind of weird situation where the `geode.properties` file says
`log-level` is one value but in fact it's another, and the `SystemProperties`
object is also in disagreement about `log-level`. I don't think the first
situation is worth worrying about - unless I'm very mistaken, you'll be in this
state even when you set `log-level` on the cache factory to a custom value.
The second, however, it seems to me we should be able to prevent.
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
> Change log level of C++ client at runtime
> -
>
> Key: GEODE-8364
> URL: https://issues.apache.org/jira/browse/GEODE-8364
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> Currently it is not possible to change log level of the C++ after it is
> created.
> It will be useful to have a way to change it at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:42 PM:
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar. The test-sources
.jars are not really needed but they make it easier for developers to
understand and maintain our tests that use LoggerContextRule.
We require use of log4j-core-n.n.n-test.jar for the LoggerContextRule (a very
useful Log4j2 JUnit Rule). Without that Rule, our geode-log4j tests require
writing LOTS of code to manipulate log4j. We could theoretically copy
LoggerContextRule and the other test classes it depends on from
log4j-core-n.n.n-test into geode-log4j but then we have to refresh that in our
code base every time we upgrade log4j dependencies or risk having the Rule fall
behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the LoggerContextRule (a very
useful Log4j2 JUnit Rule). Without that Rule, our geode-log4j tests require
writing LOTS of code to manipulate log4j. We could theoretically copy
LoggerContextRule and the other test classes it depends on from
log4j-core-n.n.n-test into geode-log4j but then we have to refresh that in our
code base every time we upgrade log4j dependencies or risk having the Rule fall
behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all file
[jira] [Comment Edited] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:41 PM:
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the LoggerContextRule (a very
useful Log4j2 JUnit Rule). Without that Rule, our geode-log4j tests require
writing LOTS of code to manipulate log4j. We could theoretically copy
LoggerContextRule and the other test classes it depends on from
log4j-core-n.n.n-test into geode-log4j but then we have to refresh that in our
code base every time we upgrade log4j dependencies or risk having the Rule fall
behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the followin
[jira] [Comment Edited] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:40 PM:
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j or jetty test jars should only be done if we want to
remove the use of log4j and jetty from Geode which is obviously more
problematic than removing Geode's use of mavenLocal(). I don't see what value
mavenLocal() provides. It's simply a huge headache to any developers who work
on both maven and gradle projects.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repositor
[jira] [Comment Edited] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:39 PM:
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j or jetty test jars should only be done if we want to
remove the use of log4j and jetty from Geode which is obviously more
problematic than removing Geode's use of mavenLocal(). I don't see what value
mavenLocal() provides. It's simply a huge headache to any developers who work
on both maven and gradle projects.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
>> Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Ru
[jira] [Comment Edited] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:35 PM:
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our tests require writing LOTS of code to manipulate log4j. We could
theoretically copy the Log4j JUnit Rule and classes it depends on from
log4j-core-n.n.n-test but then we have to refresh that in our code base every
time we upgrade log4j dependencies or we risk having the Rule fall behind.
The issue with Jetty is similar.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
>> Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 3: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-core:compileIntegrationTestJava'.
[jira] [Assigned] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-2113: -- Assignee: Dave Barnes (was: Joey McAllister) > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Addison >Assignee: Dave Barnes >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6753) Use of mavenLocal in gradle may cause build to fail with missing tests dependencies
[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund commented on GEODE-6753:
--
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our tests require writing LOTS of code to manipulate log4j. We could
theoretically copy the Log4j JUnit Rule and classes it depends on from
log4j-core-n.n.n-test but then we have to refresh that in our code base every
time we upgrade log4j dependencies or we risk having the Rule fall behind.
The issue with Jetty is similar.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> ---
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
>> Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
>> Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> 3: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':geode-core:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':geode-core:integrationTestCompileClasspath'.
>> Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
>> Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --
[jira] [Commented] (GEODE-8367) Stopped parallel gateway sender still adds events into tmpDroppedEvents
[
https://issues.apache.org/jira/browse/GEODE-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160097#comment-17160097
]
ASF GitHub Bot commented on GEODE-8367:
---
DonalEvans commented on a change in pull request #5381:
URL: https://github.com/apache/geode/pull/5381#discussion_r456569959
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/AbstractGatewaySender.java
##
@@ -1034,9 +1036,17 @@ public void distribute(EnumListenerEvent operation,
EntryEventImpl event,
// If this gateway is not running, return
if (!isRunning()) {
if (this.isPrimary()) {
- tmpDroppedEvents.add(clonedEvent);
- if (isDebugEnabled) {
-logger.debug("add to tmpDroppedEvents for evnet {}", clonedEvent);
+ if (this.startTime < 0
+ && System.currentTimeMillis() + this.startTime <
maxWaitTimeForSenderToStart) {
+tmpDroppedEvents.add(clonedEvent);
+if (isDebugEnabled) {
+ logger.debug("add to tmpDroppedEvents for evnet {}",
clonedEvent);
+}
+ } else {
+if (isDebugEnabled) {
+ logger.debug("The sender is stopped. Not to add to
tmpDroppedEvents for event {}",
Review comment:
This might be worded better as "Gateway sender is stopped. Event was not
added to tmpDroppedEvents: {}"
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
> Stopped parallel gateway sender still adds events into tmpDroppedEvents
> ---
>
> Key: GEODE-8367
> URL: https://issues.apache.org/jira/browse/GEODE-8367
> Project: Geode
> Issue Type: Improvement
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: pull-request-available
>
> In GEODE-4942, we introduced tmpDroppedEvents to save the in-coming events
> when the parallel gateway sender is restarting. However, we did not consider
> the case that the sender could be purposely stopped.
> Even for the stopped sender, the events are continuously saved into
> tmpDroppedEvents, which used a lot of memory.
> We should determine if the sender is in the middle of restarting or purposely
> stopped.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7116) CI Failure: PartitionedRegionSingleHopDUnitTest > testServerLocationRemovalThroughPing
[ https://issues.apache.org/jira/browse/GEODE-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-7116: Labels: caching-applications flaky (was: flaky) > CI Failure: PartitionedRegionSingleHopDUnitTest > > testServerLocationRemovalThroughPing > -- > > Key: GEODE-7116 > URL: https://issues.apache.org/jira/browse/GEODE-7116 > Project: Geode > Issue Type: Bug >Reporter: Donal Evans >Priority: Major > Labels: caching-applications, flaky > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1008 > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest > > testServerLocationRemovalThroughPing FAILED > java.lang.AssertionError: expected:<4> but was:<0> > 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.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing(PartitionedRegionSingleHopDUnitTest.java:679) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-7116) CI Failure: PartitionedRegionSingleHopDUnitTest > testServerLocationRemovalThroughPing
[
https://issues.apache.org/jira/browse/GEODE-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reopened GEODE-7116:
-
Assignee: (was: Ivan Godwin)
This is reproduced in:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/366
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a
lambda expression in
org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest that uses
java.util.Map, java.util.Maporg.apache.geode.cache.Region,
org.apache.geode.cache.Regionorg.apache.geode.cache.Region,
org.apache.geode.cache.Regionorg.apache.geode.cache.Region,
org.apache.geode.cache.Regionorg.apache.geode.cache.Region
Expected size:<4> but was:<3> in:
<{"/CUSTOMER"=org.apache.geode.cache.client.internal.ClientPartitionAdvisor@711fdd89,
"/ORDER"=org.apache.geode.cache.client.internal.ClientPartitionAdvisor@55e42cbf,
"/single_hop_pr"=org.apache.geode.cache.client.internal.ClientPartitionAdvisor@4d67419a}>
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.PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing(PartitionedRegionSingleHopDUnitTest.java:601)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at
org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:124)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.d
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160055#comment-17160055 ] Kirk Lund commented on GEODE-6183: -- We believe that the machine performed an update of Java. This caused the tools.jar to be unavailable only while this test was executing. There are many other tests that use the Attach API which passed in this test job suggesting that it was only a momentary problem. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160049#comment-17160049
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456550193
##
File path: geode-core/src/main/java/org/apache/geode/internal/tcp/MsgReader.java
##
@@ -14,70 +14,65 @@
*/
package org.apache.geode.internal.tcp;
+import java.io.EOFException;
import java.io.IOException;
-import java.nio.BufferUnderflowException;
+import java.io.InputStream;
+import java.net.Socket;
import java.nio.ByteBuffer;
-import org.apache.logging.log4j.Logger;
-
import org.apache.geode.distributed.internal.DMStats;
import org.apache.geode.distributed.internal.DistributionMessage;
import org.apache.geode.distributed.internal.ReplyProcessor21;
import org.apache.geode.internal.Assert;
import org.apache.geode.internal.InternalDataSerializer;
import org.apache.geode.internal.net.BufferPool;
-import org.apache.geode.internal.net.NioFilter;
+import org.apache.geode.internal.net.SocketUtils;
import org.apache.geode.internal.serialization.Version;
-import org.apache.geode.logging.internal.log4j.api.LogService;
/**
* This class is currently used for reading direct ack responses It should
probably be used for all
* of the reading done in Connection.
*
*/
public class MsgReader {
- private static final Logger logger = LogService.getLogger();
-
- protected final Connection conn;
+ protected final ClusterConnection conn;
+ private final BufferPool bufferPool;
protected final Header header = new Header();
- private final NioFilter ioFilter;
private ByteBuffer peerNetData;
+ private final InputStream inputStream;
private final ByteBufferInputStream byteBufferInputStream;
+ private int lastProcessedPosition;
+ private int lastReadPosition;
Review comment:
Let me say a little more about these variables - my understanding of
doing this external book-keeping on the buffer is to avoid a compaction when
there is still room in the buffer to read more data. The code in
ClusterConnection that reads messages still does that compaction and we should
eventually remove it and use MsgReader to read all messages.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
[ https://issues.apache.org/jira/browse/GEODE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-8368: - Description: Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. See GEODE-8150. There were performance issues with 4.8.78 that caused us to rollback to 4.8.52. We'll need to do extra testing as well as review of ClassGraph release notes and bugs. was:Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87 > --- > > Key: GEODE-8368 > URL: https://issues.apache.org/jira/browse/GEODE-8368 > Project: Geode > Issue Type: Wish > Components: build, management >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. > See GEODE-8150. There were performance issues with 4.8.78 that caused us to > rollback to 4.8.52. We'll need to do extra testing as well as review of > ClassGraph release notes and bugs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
[
https://issues.apache.org/jira/browse/GEODE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160033#comment-17160033
]
Juan Ramos commented on GEODE-8368:
---
Hello [~klund], just FYI, we had some performance issues with versions of
{{classgraph}} greater than {{4.8.52}}, that's why the version itself was
downgraded. More details in GEODE-8150.
> Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
> ---
>
> Key: GEODE-8368
> URL: https://issues.apache.org/jira/browse/GEODE-8368
> Project: Geode
> Issue Type: Wish
> Components: build, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Upgrade ClassGraph dependency from 4.8.52 to 4.8.87.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
[ https://issues.apache.org/jira/browse/GEODE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160031#comment-17160031 ] ASF GitHub Bot commented on GEODE-8368: --- kirklund opened a new pull request #5382: URL: https://github.com/apache/geode/pull/5382 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 > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87 > --- > > Key: GEODE-8368 > URL: https://issues.apache.org/jira/browse/GEODE-8368 > Project: Geode > Issue Type: Wish > Components: build, management >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
[ https://issues.apache.org/jira/browse/GEODE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8368: -- Labels: pull-request-available (was: ) > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87 > --- > > Key: GEODE-8368 > URL: https://issues.apache.org/jira/browse/GEODE-8368 > Project: Geode > Issue Type: Wish > Components: build, management >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
[ https://issues.apache.org/jira/browse/GEODE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-8368: Assignee: Kirk Lund > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87 > --- > > Key: GEODE-8368 > URL: https://issues.apache.org/jira/browse/GEODE-8368 > Project: Geode > Issue Type: Wish > Components: build, management >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8368) Upgrade ClassGraph dependency from 4.8.52 to 4.8.87
Kirk Lund created GEODE-8368: Summary: Upgrade ClassGraph dependency from 4.8.52 to 4.8.87 Key: GEODE-8368 URL: https://issues.apache.org/jira/browse/GEODE-8368 Project: Geode Issue Type: Wish Components: build, management Reporter: Kirk Lund Upgrade ClassGraph dependency from 4.8.52 to 4.8.87. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[
https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160021#comment-17160021
]
ASF GitHub Bot commented on GEODE-8364:
---
pivotal-jbarrett commented on a change in pull request #629:
URL: https://github.com/apache/geode-native/pull/629#discussion_r456531368
##
File path: cppcache/test/CacheTest.cpp
##
@@ -61,3 +62,10 @@ TEST(CacheTest, close) {
EXPECT_THROW(cache.readyForEvents(), CacheClosedException);
EXPECT_THROW(cache.rootRegions(), CacheClosedException);
}
+
+TEST(CacheTest, changeLogLevel) {
+ auto cache = CacheFactory{}.set("log-level", "info").create();
+ ASSERT_EQ(cache.getLogLevel(), LogLevel::Info);
Review comment:
What happens if you call `cache.getSystemProperties().getLogLevel()`
after changing it via `Cache`?
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
> Change log level of C++ client at runtime
> -
>
> Key: GEODE-8364
> URL: https://issues.apache.org/jira/browse/GEODE-8364
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> Currently it is not possible to change log level of the C++ after it is
> created.
> It will be useful to have a way to change it at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[
https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160020#comment-17160020
]
ASF GitHub Bot commented on GEODE-8364:
---
pivotal-jbarrett commented on a change in pull request #629:
URL: https://github.com/apache/geode-native/pull/629#discussion_r456530395
##
File path: cppcache/include/geode/Cache.hpp
##
@@ -239,6 +241,10 @@ class APACHE_GEODE_EXPORT Cache : public GeodeCache {
SystemProperties& getSystemProperties() const override;
+ void setLogLevel(LogLevel newLevel);
Review comment:
Please add documentation to these new methods.
##
File path: cppcache/test/CacheTest.cpp
##
@@ -61,3 +62,10 @@ TEST(CacheTest, close) {
EXPECT_THROW(cache.readyForEvents(), CacheClosedException);
EXPECT_THROW(cache.rootRegions(), CacheClosedException);
}
+
+TEST(CacheTest, changeLogLevel) {
+ auto cache = CacheFactory{}.set("log-level", "info").create();
+ ASSERT_EQ(cache.getLogLevel(), LogLevel::Info);
Review comment:
What happens if you call `cache.getSystemProperties.getLogLevel()` after
changing it via `Cache`?
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
> Change log level of C++ client at runtime
> -
>
> Key: GEODE-8364
> URL: https://issues.apache.org/jira/browse/GEODE-8364
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> Currently it is not possible to change log level of the C++ after it is
> created.
> It will be useful to have a way to change it at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160013#comment-17160013
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456523975
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketUtils.java
##
@@ -89,6 +89,10 @@ public static boolean close(final ServerSocket serverSocket)
{
* and buffer.remaining is also zero the limit is changed to be
buffer.capacity
* before reading.
*
+ * @param socket the socket to read from
+ * @param inputBuffer the buffer into which data should be stored
+ * @param socketInputStream the socket's inputStream, included as a
parameter so it can be a
+ *buffered stream, if desired
Review comment:
The older Old IO code base used a BufferedInputStream wrapper around the
socket's input stream on recommendation from StackOverflow and other sources.
I did not find that it increased performance so I removed that wrapper, but I
left this parameter in place for flexibility since this is a "Util" class.
This parameter also makes the methods easier to test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160012#comment-17160012
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456522212
##
File path:
geode-core/src/test/java/org/apache/geode/internal/net/SocketUtilsJUnitTest.java
##
@@ -88,4 +95,86 @@ public void testCloseServerSocketThrowsIOException() throws
IOException {
public void testCloseServerSocketWithNull() {
assertThat(SocketUtils.close((ServerSocket) null)).isTrue();
}
+
+ @Test
+ public void readFromSocketWithHeapBuffer() throws IOException {
+Socket socket = mock(Socket.class);
+SocketChannel channel = mock(SocketChannel.class);
+when(socket.getChannel()).thenReturn(channel);
+final ByteBuffer buffer = ByteBuffer.allocate(100); // heap buffer
+byte[] bytes = new byte[100];
+InputStream stream = new ByteArrayInputStream(bytes);
+when(channel.read(buffer)).thenAnswer((answer) -> {
+ buffer.put(bytes);
+ return buffer.position();
+});
+assertThat(buffer.hasArray()).isTrue();
+SocketUtils.readFromSocket(socket, buffer, stream);
+// the channel was used to read the bytes
+verify(channel, times(1)).read(buffer);
+// the buffer was filled
+assertThat(buffer.position()).isEqualTo(bytes.length);
+// the stream was not used
+assertThat(stream.available()).isEqualTo(bytes.length);
+ }
+
+
+ @Test
+ public void readFromSocketWithDirectBuffer() throws IOException {
+Socket socket = mock(Socket.class);
+SocketChannel channel = mock(SocketChannel.class);
+when(socket.getChannel()).thenReturn(channel);
+final ByteBuffer buffer = ByteBuffer.allocateDirect(100); // non-heap
buffer
Review comment:
I don't like to factor out code in tests too much. It leads to tests
that are difficult to understand. Short tests like this should be easy to read
and stand on their own.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160006#comment-17160006
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456520985
##
File path:
geode-core/src/main/java/org/apache/geode/internal/tcp/ClusterConnection.java
##
@@ -1142,31 +1154,46 @@ private Connection(ConnectionTable t, boolean
preserveOrder, InternalDistributed
InetSocketAddress addr =
new InetSocketAddress(remoteID.getInetAddress(),
remoteID.getDirectChannelPort());
-SocketChannel channel = SocketChannel.open();
-owner.addConnectingSocket(channel.socket(), addr.getAddress());
-
-try {
- channel.socket().setTcpNoDelay(true);
- channel.socket().setKeepAlive(SocketCreator.ENABLE_TCP_KEEP_ALIVE);
+int connectTime = getP2PConnectTimeout(conduit.getDM().getConfig());
+boolean useSSL = getConduit().useSSL();
+if (useSSL) {
+ int socketBufferSize =
+ sharedResource ? SMALL_BUFFER_SIZE :
this.owner.getConduit().tcpBufferSize;
+ socket = getConduit().getSocketCreator().forAdvancedUse().connect(
+ new HostAndPort(remoteID.getHostName(),
remoteID.getDirectChannelPort()),
+ 0, null, false, socketBufferSize, true);
+ setSocketBufferSize(this.socket, false, socketBufferSize, true);
+} else {
+ SocketChannel channel = SocketChannel.open();
+ socket = channel.socket();
// If conserve-sockets is false, the socket can be used for receiving
responses, so set the
// receive buffer accordingly.
if (!sharedResource) {
-setReceiveBufferSize(channel.socket(),
owner.getConduit().tcpBufferSize);
+setReceiveBufferSize(socket, owner.getConduit().tcpBufferSize);
} else {
-setReceiveBufferSize(channel.socket(), SMALL_BUFFER_SIZE); // make
small since only
+setReceiveBufferSize(socket, SMALL_BUFFER_SIZE); // make small since
only
// receive ack messages
}
- setSendBufferSize(channel.socket());
- channel.configureBlocking(true);
+}
+owner.addConnectingSocket(socket, addr.getAddress());
+
+try {
+ socket.setTcpNoDelay(true);
+ socket.setKeepAlive(SocketCreator.ENABLE_TCP_KEEP_ALIVE);
- int connectTime = getP2PConnectTimeout(conduit.getDM().getConfig());
+ setSendBufferSize(socket);
+ if (!useSSL) {
+socket.getChannel().configureBlocking(true);
+ }
try {
-channel.socket().connect(addr, connectTime);
-
-createIoFilter(channel, true);
+if (!useSSL) {
+ // haven't connected yet
+ socket.connect(addr, connectTime);
+}
+configureInputStream(socket, true);
Review comment:
"client" socket is a term from TLS, where one side must be the "client"
and the other side is the "server".
The sockets in this class may be one-way or may be bidirectional. "Shared"
connections (those shared between threads) are one-way. Thread-owned
connections are bidirectional. A P2P "reader" thread reads from the socket and
DirectReplyProcessor writes responses.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160002#comment-17160002
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456519045
##
File path: geode-core/src/main/java/org/apache/geode/internal/tcp/MsgReader.java
##
@@ -14,70 +14,65 @@
*/
package org.apache.geode.internal.tcp;
+import java.io.EOFException;
import java.io.IOException;
-import java.nio.BufferUnderflowException;
+import java.io.InputStream;
+import java.net.Socket;
import java.nio.ByteBuffer;
-import org.apache.logging.log4j.Logger;
-
import org.apache.geode.distributed.internal.DMStats;
import org.apache.geode.distributed.internal.DistributionMessage;
import org.apache.geode.distributed.internal.ReplyProcessor21;
import org.apache.geode.internal.Assert;
import org.apache.geode.internal.InternalDataSerializer;
import org.apache.geode.internal.net.BufferPool;
-import org.apache.geode.internal.net.NioFilter;
+import org.apache.geode.internal.net.SocketUtils;
import org.apache.geode.internal.serialization.Version;
-import org.apache.geode.logging.internal.log4j.api.LogService;
/**
* This class is currently used for reading direct ack responses It should
probably be used for all
* of the reading done in Connection.
*
*/
public class MsgReader {
- private static final Logger logger = LogService.getLogger();
-
- protected final Connection conn;
+ protected final ClusterConnection conn;
+ private final BufferPool bufferPool;
protected final Header header = new Header();
- private final NioFilter ioFilter;
private ByteBuffer peerNetData;
+ private final InputStream inputStream;
private final ByteBufferInputStream byteBufferInputStream;
+ private int lastProcessedPosition;
+ private int lastReadPosition;
Review comment:
I'm not going to change that logic. It's what used to be in the
MsgReader subclasses before I moved it to the NioFilter classes. This PR just
restores that logic to MsgReader.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160005#comment-17160005
]
ASF GitHub Bot commented on GEODE-8349:
---
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456519338
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketUtils.java
##
@@ -73,4 +82,49 @@ public static boolean close(final ServerSocket serverSocket)
{
return true;
}
+ /**
+ * Read data from the given socket into the given ByteBuffer. If NIO is
supported
+ * we use Channel.read(ByteBuffer). If not we use byte arrays to read
available
+ * bytes or buffer.remaining() bytes, whichever is smaller. If buffer.limit
is zero
+ * and buffer.remaining is also zero the limit is changed to be
buffer.capacity
+ * before reading.
+ *
+ * @return the number of bytes read, which may be -1 for EOF
+ */
+ public static int readFromSocket(Socket socket, ByteBuffer inputBuffer,
+ InputStream socketInputStream) throws IOException {
+int amountRead;
+inputBuffer.limit(inputBuffer.capacity());
+if (socket instanceof SSLSocket) {
+ amountRead = readFromStream(socketInputStream, inputBuffer);
+} else {
+ amountRead = socket.getChannel().read(inputBuffer);
+}
+return amountRead;
+ }
+
+ private static int readFromStream(InputStream stream, ByteBuffer
inputBuffer) throws IOException {
+int amountRead;
+// if bytes are available we read that number of bytes. Otherwise we do a
blocking read
+// of buffer.remaining() bytes
+int amountToRead = inputBuffer.remaining();
+// stream.available() > 0 ? Math.min(stream.available(),
inputBuffer.remaining())
+// : inputBuffer.remaining();
+if (inputBuffer.hasArray()) {
+ amountRead = stream.read(inputBuffer.array(),
+ inputBuffer.arrayOffset() + inputBuffer.position(), amountToRead);
+ if (amountRead > 0) {
+inputBuffer.position(inputBuffer.position() + amountRead);
+ }
+} else {
Review comment:
I've added tests for this, so I'm resolving this thread.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
>
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[ https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8349: -- Labels: pull-request-available (was: ) > reinstate use of SSLSocket for cluster communication > > > Key: GEODE-8349 > URL: https://issues.apache.org/jira/browse/GEODE-8349 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > > We've found problems with "new IO"'s SSLEngine with respect to support for > TLSV1. We've also seen anomalous performance using that secure > communications mechanism. The introduction of the use of the "new IO" > SSLEngine was originally to 1) reduce code complexity in the > org.apache.geode.internal.tcp package and 2) to set the stage for its use in > client/server communications so that selectors could be used in c/s > communications. > This ticket aims to reintroduce the use of SSLSocket in cluster > communications without restoring the old, poorly tested SSL code paths. The > new implementation should have as good or better performance than the > previous"old IO" implementation and the more recent "new IO" SSLEngine > implementation as well. This should be apparent in the CI benchmark jobs. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8365) Redis delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8365. Fix Version/s: 1.14.0 Resolution: Fixed > Redis delta not propagating updated hash values properly > > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Redis delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8365) Redis delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159932#comment-17159932 ] ASF subversion and git services commented on GEODE-8365: Commit 28fb073f075d598608c99cdce03e611f3f633c4a in geode's branch refs/heads/develop from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=28fb073 ] GEODE-8365: Redis Delta not propagating updated hash values properly (#5377) > Redis delta not propagating updated hash values properly > > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Redis delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8365) Redis delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159931#comment-17159931 ] ASF GitHub Bot commented on GEODE-8365: --- jdeppe-pivotal merged pull request #5377: URL: https://github.com/apache/geode/pull/5377 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 > Redis delta not propagating updated hash values properly > > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Redis delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[ https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159793#comment-17159793 ] ASF GitHub Bot commented on GEODE-8364: --- alb3rtobr commented on pull request #629: URL: https://github.com/apache/geode-native/pull/629#issuecomment-659983218 It will be useful for us to have this feature in order to get more info when there is a problem with the client. If we detect an issue in the client, we can activate debug log to get more info about what is happening. This will help a lot our engineers to troubleshoot and report problems. 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 > Change log level of C++ client at runtime > - > > Key: GEODE-8364 > URL: https://issues.apache.org/jira/browse/GEODE-8364 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Currently it is not possible to change log level of the C++ after it is > created. > It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
