[jira] [Assigned] (GEODE-7676) All eviction tasks are cleared after a Partitioned Region is cleared
[ https://issues.apache.org/jira/browse/GEODE-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos reassigned GEODE-7676: - Assignee: Juan Ramos > All eviction tasks are cleared after a Partitioned Region is cleared > > > Key: GEODE-7676 > URL: https://issues.apache.org/jira/browse/GEODE-7676 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > > Clear operations are successful and all the eviction tasks are cleared in the > bucket level > > Acceptance : > * DUnit tests ensuring that clear operations are successful > * Eviction tasks are cleared > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7949) Geode Redis - Get/Set commands for RedisString datatype to cover new parameters
Venkateswara Prasath Durairaj created GEODE-7949: Summary: Geode Redis - Get/Set commands for RedisString datatype to cover new parameters Key: GEODE-7949 URL: https://issues.apache.org/jira/browse/GEODE-7949 Project: Geode Issue Type: Improvement Components: redis Reporter: Venkateswara Prasath Durairaj Adding more support for more parameters to the existing implementation of Get/Set commands in GeodeRedis module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7950) Packer script for Windows uses old TLS and fails to connect
Robert Houghton created GEODE-7950:
--
Summary: Packer script for Windows uses old TLS and fails to
connect
Key: GEODE-7950
URL: https://issues.apache.org/jira/browse/GEODE-7950
Project: Geode
Issue Type: Bug
Components: build, ci
Reporter: Robert Houghton
>From Concourse:
{code:java}
googlecompute: WARNING: Unable to download the list of available providers.
Check your internet connection.
googlecompute: WARNING: Unable to download from URI
'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
==> googlecompute: Install-PackageProvider : No match was found for the
specified search criteria for the provider 'NuGet'. The package
==> googlecompute: provider requires 'PackageManagement' and 'Provider' tags.
Please check if the specified package has the tags.
==> googlecompute: At
C:\Windows\Temp\script-5e8b39e5-819f-74b9-9a4b-7470e3b783b6.ps1:3 char:1
==> googlecompute: + Install-PackageProvider -Name NuGet -MinimumVersion
2.8.5.201 -Force
==> googlecompute: +
==> googlecompute: + CategoryInfo : InvalidArgument:
(Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
==> googlecompute:kageProvider], Exception
==> googlecompute: + FullyQualifiedErrorId :
NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
==> googlecompute:vider
==> googlecompute:
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7950) Packer script for Windows uses old TLS and fails to connect
[
https://issues.apache.org/jira/browse/GEODE-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Houghton reassigned GEODE-7950:
--
Assignee: Robert Houghton
> Packer script for Windows uses old TLS and fails to connect
> ---
>
> Key: GEODE-7950
> URL: https://issues.apache.org/jira/browse/GEODE-7950
> Project: Geode
> Issue Type: Bug
> Components: build, ci
>Reporter: Robert Houghton
>Assignee: Robert Houghton
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From Concourse:
> {code:java}
> googlecompute: WARNING: Unable to download the list of available providers.
> Check your internet connection.
> googlecompute: WARNING: Unable to download from URI
> 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
> ==> googlecompute: Install-PackageProvider : No match was found for the
> specified search criteria for the provider 'NuGet'. The package
> ==> googlecompute: provider requires 'PackageManagement' and 'Provider' tags.
> Please check if the specified package has the tags.
> ==> googlecompute: At
> C:\Windows\Temp\script-5e8b39e5-819f-74b9-9a4b-7470e3b783b6.ps1:3 char:1
> ==> googlecompute: + Install-PackageProvider -Name NuGet -MinimumVersion
> 2.8.5.201 -Force
> ==> googlecompute: +
>
> ==> googlecompute: + CategoryInfo : InvalidArgument:
> (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
> ==> googlecompute:kageProvider], Exception
> ==> googlecompute: + FullyQualifiedErrorId :
> NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
> ==> googlecompute:vider
> ==> googlecompute:
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6819.
--
Fix Version/s: 1.13.0
Resolution: Fixed
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076447#comment-17076447 ] ASF subversion and git services commented on GEODE-7098: Commit abd0f54dd280b64473a4ef36149d31de4a74da1d in geode's branch refs/heads/develop from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=abd0f54 ] GEODE-7098: Tomcat8SessionsClientServerDUnitTest Tests were getting bind failures (#4903) * GEODE-7098: Tests were getting bind failures using SocketUtils.getAvailableTCPPort - Moved tests to use AvailablePortHelper class - Added Sanity check to setup - Rename testSanity call to basicConnectivityCheck - Inline testSanity Co-authored-by: Mark Hanson > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Time Spent: 1h 10m > Remaining Estimate: 0h > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076448#comment-17076448 ] ASF subversion and git services commented on GEODE-7098: Commit abd0f54dd280b64473a4ef36149d31de4a74da1d in geode's branch refs/heads/develop from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=abd0f54 ] GEODE-7098: Tomcat8SessionsClientServerDUnitTest Tests were getting bind failures (#4903) * GEODE-7098: Tests were getting bind failures using SocketUtils.getAvailableTCPPort - Moved tests to use AvailablePortHelper class - Added Sanity check to setup - Rename testSanity call to basicConnectivityCheck - Inline testSanity Co-authored-by: Mark Hanson > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Time Spent: 1h 10m > Remaining Estimate: 0h > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7892) Code improvements for ConnectionProxyJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076455#comment-17076455
]
ASF subversion and git services commented on GEODE-7892:
Commit 087e47a33f51523c07fa15221be16f069e13b1c4 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=087e47a ]
Merge pull request #4827 from Nordix/feature/GEODE-7892
GEODE-7892: Code improvements in ConnectionProxyJUnitTest
> Code improvements for ConnectionProxyJUnitTest
> --
>
> Key: GEODE-7892
> URL: https://issues.apache.org/jira/browse/GEODE-7892
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I was taking a look to {{ConnectionProxyJUnitTest}} and I realized that
> {{verifyAckSend and verifyExpiry methods were not using their timeToWait}}
> parameter, so in fact they were using the default {{GeodeAwaitability}}
> timeout value (5 minutes).
> I changed that and then I realized different calls to both methods were using
> different timeouts. And the one used for {{verifyExpiry}} in
> {{testPeriodicAckSendByClient}} was causing the test to fail, so I decided to
> homogenize calls to the same method, using a common timeout (the two new
> Duration objects in the class).
> And finally I removed the usage of deprecated {{WaitCriterion}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7892) Code improvements for ConnectionProxyJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076454#comment-17076454
]
ASF subversion and git services commented on GEODE-7892:
Commit 24203d86f2cc99c686e042fd87d4359ad9389d56 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=24203d8 ]
GEODE-7892: Code improvements in ConnectionProxyJUnitTest
> Code improvements for ConnectionProxyJUnitTest
> --
>
> Key: GEODE-7892
> URL: https://issues.apache.org/jira/browse/GEODE-7892
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I was taking a look to {{ConnectionProxyJUnitTest}} and I realized that
> {{verifyAckSend and verifyExpiry methods were not using their timeToWait}}
> parameter, so in fact they were using the default {{GeodeAwaitability}}
> timeout value (5 minutes).
> I changed that and then I realized different calls to both methods were using
> different timeouts. And the one used for {{verifyExpiry}} in
> {{testPeriodicAckSendByClient}} was causing the test to fail, so I decided to
> homogenize calls to the same method, using a common timeout (the two new
> Duration objects in the class).
> And finally I removed the usage of deprecated {{WaitCriterion}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7892) Code improvements for ConnectionProxyJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076456#comment-17076456
]
ASF subversion and git services commented on GEODE-7892:
Commit 087e47a33f51523c07fa15221be16f069e13b1c4 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=087e47a ]
Merge pull request #4827 from Nordix/feature/GEODE-7892
GEODE-7892: Code improvements in ConnectionProxyJUnitTest
> Code improvements for ConnectionProxyJUnitTest
> --
>
> Key: GEODE-7892
> URL: https://issues.apache.org/jira/browse/GEODE-7892
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I was taking a look to {{ConnectionProxyJUnitTest}} and I realized that
> {{verifyAckSend and verifyExpiry methods were not using their timeToWait}}
> parameter, so in fact they were using the default {{GeodeAwaitability}}
> timeout value (5 minutes).
> I changed that and then I realized different calls to both methods were using
> different timeouts. And the one used for {{verifyExpiry}} in
> {{testPeriodicAckSendByClient}} was causing the test to fail, so I decided to
> homogenize calls to the same method, using a common timeout (the two new
> Duration objects in the class).
> And finally I removed the usage of deprecated {{WaitCriterion}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7951) eliminate UDP communication
Bill Burcham created GEODE-7951: --- Summary: eliminate UDP communication Key: GEODE-7951 URL: https://issues.apache.org/jira/browse/GEODE-7951 Project: Geode Issue Type: New Feature Components: membership Reporter: Bill Burcham UDP communication in Geode is not as secure as it should be. Replace that UDP communcation (in the membership subsystem) with TCP communication so we can inherit the security setting and machinery. This feature will be added initially as experimental and optional so we can get the new code into the main line of development and iterate on it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7892) Code improvements for ConnectionProxyJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes resolved GEODE-7892.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> Code improvements for ConnectionProxyJUnitTest
> --
>
> Key: GEODE-7892
> URL: https://issues.apache.org/jira/browse/GEODE-7892
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I was taking a look to {{ConnectionProxyJUnitTest}} and I realized that
> {{verifyAckSend and verifyExpiry methods were not using their timeToWait}}
> parameter, so in fact they were using the default {{GeodeAwaitability}}
> timeout value (5 minutes).
> I changed that and then I realized different calls to both methods were using
> different timeouts. And the one used for {{verifyExpiry}} in
> {{testPeriodicAckSendByClient}} was causing the test to fail, so I decided to
> homogenize calls to the same method, using a common timeout (the two new
> Duration objects in the class).
> And finally I removed the usage of deprecated {{WaitCriterion}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7952) Queries Don't Work With .NET Autoserializer
Michael Martell created GEODE-7952: -- Summary: Queries Don't Work With .NET Autoserializer Key: GEODE-7952 URL: https://issues.apache.org/jira/browse/GEODE-7952 Project: Geode Issue Type: Bug Components: native client Reporter: Michael Martell When testing the autoserializer for .NET, I discovered that queries against autoserialized data always returns an empty result set. The attached is a modified version of an existing query test which demonstrates the problem. Also, this has been reported earlier but a ticket was never filed. Workaround was to not use the autoserializer. [https://community.pivotal.io/s/article/Unable-to-get-result-in-Native-Client-by-query-with-specified-condition-and-ReflectionBasedAutoSerializer] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7940) A parallel GatewaySender stops sending events if another GatewaySender that was attached to the same region is destroyed
[ https://issues.apache.org/jira/browse/GEODE-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos reassigned GEODE-7940: - Assignee: Juan Ramos > A parallel GatewaySender stops sending events if another GatewaySender that > was attached to the same region is destroyed > > > Key: GEODE-7940 > URL: https://issues.apache.org/jira/browse/GEODE-7940 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Barrett Oglesby >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Attachments: create-sender-alter-region-all-gfsh_04-01-2020.tgz > > > The attached test reproduces this issue. It has a readme that describes how > to run it. > It starts 3 distributed systems named ln, ny and tk. > ny and tk each have a gateway receiver and a region defined. > Use gfsh in ln to: > 1. Create sender to ny > 2. Create region with sender to ny > 3. Start doing puts from a client (verify updates are happening in ny) > 4. Create sender to tk > 5. Alter region add sender to tk (verify updates are happening in tk) > 6. Stop sender to ny > 7. Alter region remove sender to ny > 8. Destroy sender to ny > Updates should stop to ny but not tk, but updates to both stop. > The ln log contains no exceptions. The stats show events being received and > queued by the sender to tk. The eventQueueSize is 0, though. > If step 8 is not done, updates continue flowing to tk. > If the ln server is restarted, updates start flowing to tk again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7944) Unable to deserialize membership id java.io.EOFException on locator only when debug is enabled and native client is used
[
https://issues.apache.org/jira/browse/GEODE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina reassigned GEODE-7944:
-
Assignee: Jakov Varenina
> Unable to deserialize membership id java.io.EOFException on locator only when
> debug is enabled and native client is used
>
>
> Key: GEODE-7944
> URL: https://issues.apache.org/jira/browse/GEODE-7944
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: locator.log, native_client.log
>
>
> During the creation of pool in geode native with subscription "enabled"
> exception java.io.EOFException is thrown on locator only when it is
> configured with _--log-level=debug_. On geode native this reflects with "No
> locators available". You can find native_client.log and locator.log in
> attachment.
> Native client code:
> {code:java}
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
> auto pool = poolFactory.addLocator("localhost", 10334)
> .setSubscriptionEnabled(true)
> .create("pool");
> {code}
> With java client everything works OK.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7953) Create Restore Redundancy Internal API
Donal Evans created GEODE-7953: -- Summary: Create Restore Redundancy Internal API Key: GEODE-7953 URL: https://issues.apache.org/jira/browse/GEODE-7953 Project: Geode Issue Type: New Feature Reporter: Donal Evans Introduce an internal API to allow redundancy to be restored and primary bucket hosts reassigned without necessitating a full rebalance. As described in the RFC found here: https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
Donal Evans created GEODE-7954:
--
Summary: Create restore redundancy and status redundancy gfsh
commands
Key: GEODE-7954
URL: https://issues.apache.org/jira/browse/GEODE-7954
Project: Geode
Issue Type: New Feature
Components: gfsh
Reporter: Donal Evans
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)] }}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region}} and {{--exclude-region}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{--dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands
Donal Evans created GEODE-7955: -- Summary: Documentation for restore redundancy internal API and gfsh commands Key: GEODE-7955 URL: https://issues.apache.org/jira/browse/GEODE-7955 Project: Geode Issue Type: Task Components: docs Reporter: Donal Evans Fully document the new features introduced in GEODE-7953 and GEODE-7954 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7954:
---
Description:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region-}} and {{-exclude-region-}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{-dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
was:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)] }}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region}} and {{--exclude-region}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{--dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
> Create restore redundancy and s
[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7954:
---
Description:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region}} and {{--exclude-region}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{--dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
was:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region-}} and {{-exclude-region-}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{-dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
> Create restore redundancy and st
[jira] [Assigned] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-7953: -- Assignee: Donal Evans > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-7955: -- Assignee: Donal Evans > Documentation for restore redundancy internal API and gfsh commands > --- > > Key: GEODE-7955 > URL: https://issues.apache.org/jira/browse/GEODE-7955 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > Fully document the new features introduced in GEODE-7953 and GEODE-7954 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7954:
---
Description:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{\-\-include-region}} and
{{\-\-exclude-region}} arguments, similar to the existing rebalance command. If
neither argument is specified, all regions will be included. Included regions
will take precedence over excluded regions when both are specified. The restore
redundancy command will also take an optional {{\-\-dont-reassign-primaries}}
argument to determine if primaries should not be reassigned during the
operation. The default behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
was:
Add two gfsh commands to allow redundancy to be restored and to check the
current redundancy status:
{{restore redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
{{status redundancy [--include-region=value(,value)*]
[--exclude-region=value(,value)*]}}
The first command will execute a function on members hosting the specified
partitioned regions and trigger the restore redundancy operation for those
regions, then report the final redundancy status of those regions.
The command will return success status if:
* At least one redundant copy exists for every bucket in regions with
redundancy configured that were included, either explicitly or implicitly.
* No partitioned regions were found and none were explicitly included.
The command will return error status if:
* At least one bucket in a region has zero redundant copies, and that region
has redundancy configured.
* At least one of the explicitly included partitioned regions is not found.
* There is a member in the system with a version of Geode older than 1.13.0
(assuming that is the version in which this feature is implemented).
* The restore redundancy function encounters an exception.
The second command will determine the current redundancy status for the
specified regions and report it to the user.
Both commands will take optional {{--include-region}} and {{--exclude-region}}
arguments, similar to the existing rebalance command. If neither argument is
specified, all regions will be included. Included regions will take precedence
over excluded regions when both are specified. The restore redundancy command
will also take an optional {{--dont-reassign-primaries}} argument to determine
if primaries should not be reassigned during the operation. The default
behaviour will be to reassign primaries.
Both commands will output a list of regions with zero redundant copies first
(unless they are configured to have zero redundancy), then regions with less
than their configured redundancy, then regions with full redundancy. The
restore redundancy command will also output information about how many
primaries were reassigned and how long that process took, similar to the
existing rebalance command.
As described here:
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
> Create restore redundancy
[jira] [Assigned] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-7954:
--
Assignee: Donal Evans
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * At least one redundant copy exists for every bucket in regions with
> redundancy configured that were included, either explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not
> be reassigned during the operation. The default behaviour will be to reassign
> primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076510#comment-17076510
]
Eric Shu commented on GEODE-7954:
-
Do we know why only one copy is needed to satisfy redundancy?
"At least one redundant copy exists for every bucket in regions"
Do this mean if redundancy is configured for 2 redundant copies, restore
redundancy command would return successfully if there is only one redundant
copy in the cluster?
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * At least one redundant copy exists for every bucket in regions with
> redundancy configured that were included, either explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not
> be reassigned during the operation. The default behaviour will be to reassign
> primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7956) Correct documentation of legal region names
Darrel Schneider created GEODE-7956: --- Summary: Correct documentation of legal region names Key: GEODE-7956 URL: https://issues.apache.org/jira/browse/GEODE-7956 Project: Geode Issue Type: Bug Components: docs Reporter: Darrel Schneider According to this: https://geode.apache.org/docs/guide/111/basic_config/data_regions/region_naming.html region names can only contain alphanumeric, dash, and underscore. But the product also supports a dot '.'. See RegionNameValidation and RegionNameValidationTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7917) Problem forming SSL connection in multisite setup
[ https://issues.apache.org/jira/browse/GEODE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076540#comment-17076540 ] ASF subversion and git services commented on GEODE-7917: Commit 552cdead5664c0b004094a136d9c419983ff38a9 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=552cdea ] GEODE-7917: change thrown exception type for SSL to IOException (#4858) * GEODE-7917: Change exception type to IOException when caused by EOFException * GEODE-7917: added test * GEODE-7917: update after comments > Problem forming SSL connection in multisite setup > - > > Key: GEODE-7917 > URL: https://issues.apache.org/jira/browse/GEODE-7917 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Attachments: javax_net_debug.log > > Time Spent: 50m > Remaining Estimate: 0h > > We are installing two sites, with one locator in each site, and TLS enabled. > Problem appears when locators on both sides are started at same time. In that > case, on both locators, immediately after they are started, > IllegalStateException is caught, and connections are never reestablished. > > javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake > at > java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at > org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) > at > org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorDiscovery.java:121) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Suppressed: java.net.SocketException: Broken pipe (Write failed) > at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) > at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) > at > java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405) > ... 10 more > Caused by: java.io.EOFException: SSL peer shut down incorrectly > at > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > ... 12 more > > If locators are restarted one by one, everything is OK. > Added log of the fault with set javax.net.debug=all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7917) Problem forming SSL connection in multisite setup
[ https://issues.apache.org/jira/browse/GEODE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076541#comment-17076541 ] ASF subversion and git services commented on GEODE-7917: Commit 552cdead5664c0b004094a136d9c419983ff38a9 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=552cdea ] GEODE-7917: change thrown exception type for SSL to IOException (#4858) * GEODE-7917: Change exception type to IOException when caused by EOFException * GEODE-7917: added test * GEODE-7917: update after comments > Problem forming SSL connection in multisite setup > - > > Key: GEODE-7917 > URL: https://issues.apache.org/jira/browse/GEODE-7917 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Attachments: javax_net_debug.log > > Time Spent: 50m > Remaining Estimate: 0h > > We are installing two sites, with one locator in each site, and TLS enabled. > Problem appears when locators on both sides are started at same time. In that > case, on both locators, immediately after they are started, > IllegalStateException is caught, and connections are never reestablished. > > javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake > at > java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at > org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) > at > org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorDiscovery.java:121) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Suppressed: java.net.SocketException: Broken pipe (Write failed) > at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) > at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) > at > java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405) > ... 10 more > Caused by: java.io.EOFException: SSL peer shut down incorrectly > at > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > ... 12 more > > If locators are restarted one by one, everything is OK. > Added log of the fault with set javax.net.debug=all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7917) Problem forming SSL connection in multisite setup
[ https://issues.apache.org/jira/browse/GEODE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076539#comment-17076539 ] ASF subversion and git services commented on GEODE-7917: Commit 552cdead5664c0b004094a136d9c419983ff38a9 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=552cdea ] GEODE-7917: change thrown exception type for SSL to IOException (#4858) * GEODE-7917: Change exception type to IOException when caused by EOFException * GEODE-7917: added test * GEODE-7917: update after comments > Problem forming SSL connection in multisite setup > - > > Key: GEODE-7917 > URL: https://issues.apache.org/jira/browse/GEODE-7917 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Attachments: javax_net_debug.log > > Time Spent: 50m > Remaining Estimate: 0h > > We are installing two sites, with one locator in each site, and TLS enabled. > Problem appears when locators on both sides are started at same time. In that > case, on both locators, immediately after they are started, > IllegalStateException is caught, and connections are never reestablished. > > javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake > at > java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at > org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) > at > org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorDiscovery.java:121) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Suppressed: java.net.SocketException: Broken pipe (Write failed) > at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) > at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) > at > java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405) > ... 10 more > Caused by: java.io.EOFException: SSL peer shut down incorrectly > at > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > ... 12 more > > If locators are restarted one by one, everything is OK. > Added log of the fault with set javax.net.debug=all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7917) Problem forming SSL connection in multisite setup
[ https://issues.apache.org/jira/browse/GEODE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076542#comment-17076542 ] ASF subversion and git services commented on GEODE-7917: Commit 552cdead5664c0b004094a136d9c419983ff38a9 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=552cdea ] GEODE-7917: change thrown exception type for SSL to IOException (#4858) * GEODE-7917: Change exception type to IOException when caused by EOFException * GEODE-7917: added test * GEODE-7917: update after comments > Problem forming SSL connection in multisite setup > - > > Key: GEODE-7917 > URL: https://issues.apache.org/jira/browse/GEODE-7917 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Attachments: javax_net_debug.log > > Time Spent: 50m > Remaining Estimate: 0h > > We are installing two sites, with one locator in each site, and TLS enabled. > Problem appears when locators on both sides are started at same time. In that > case, on both locators, immediately after they are started, > IllegalStateException is caught, and connections are never reestablished. > > javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake > at > java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at > org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) > at > org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorDiscovery.java:121) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Suppressed: java.net.SocketException: Broken pipe (Write failed) > at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) > at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) > at > java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405) > ... 10 more > Caused by: java.io.EOFException: SSL peer shut down incorrectly > at > java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) > ... 12 more > > If locators are restarted one by one, everything is OK. > Added log of the fault with set javax.net.debug=all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7941) upgrade Shiro to 1.5.2
[ https://issues.apache.org/jira/browse/GEODE-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076546#comment-17076546 ] ASF subversion and git services commented on GEODE-7941: Commit 8a9490bb617c099907dc37ad4d161c31ec7b4f63 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8a9490b ] GEODE-7941: update Shiro to recommended version 1.5.2 (#4896) * GEODE-7941: update Shiro to recommended version 1.5.2 * update in dependency_classpath.txt and assembly_content.txt (cherry picked from commit 6fffd5c07a2f67575ccec6d19df48c70a51ab1c3) > upgrade Shiro to 1.5.2 > -- > > Key: GEODE-7941 > URL: https://issues.apache.org/jira/browse/GEODE-7941 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > our current Shiro version (1.4.1) is below the recommended version. Now that > Geode 1.12.0 has been released, now is a good time to bump whatever we can. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7941) upgrade Shiro to 1.5.2
[ https://issues.apache.org/jira/browse/GEODE-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076545#comment-17076545 ] ASF subversion and git services commented on GEODE-7941: Commit 8a9490bb617c099907dc37ad4d161c31ec7b4f63 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8a9490b ] GEODE-7941: update Shiro to recommended version 1.5.2 (#4896) * GEODE-7941: update Shiro to recommended version 1.5.2 * update in dependency_classpath.txt and assembly_content.txt (cherry picked from commit 6fffd5c07a2f67575ccec6d19df48c70a51ab1c3) > upgrade Shiro to 1.5.2 > -- > > Key: GEODE-7941 > URL: https://issues.apache.org/jira/browse/GEODE-7941 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > our current Shiro version (1.4.1) is below the recommended version. Now that > Geode 1.12.0 has been released, now is a good time to bump whatever we can. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7941) upgrade Shiro to 1.5.2
[ https://issues.apache.org/jira/browse/GEODE-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7941: Fix Version/s: 1.12.1 > upgrade Shiro to 1.5.2 > -- > > Key: GEODE-7941 > URL: https://issues.apache.org/jira/browse/GEODE-7941 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.12.1, 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > our current Shiro version (1.4.1) is below the recommended version. Now that > Geode 1.12.0 has been released, now is a good time to bump whatever we can. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7957) Serializing and deserializing a CumulativeNonDistinctResults containing Structs fails with either an OutOfMemoryError or an IllegalArgumentException
Barrett Oglesby created GEODE-7957:
--
Summary: Serializing and deserializing a
CumulativeNonDistinctResults containing Structs fails with either an
OutOfMemoryError or an IllegalArgumentException
Key: GEODE-7957
URL: https://issues.apache.org/jira/browse/GEODE-7957
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Barrett Oglesby
Executing a query like:
{noformat}
SELECT pnl.TM_ID, pnl.PTD_ACCRETION_INV_AMT, pnl.FIRM_ACCT_ID, pnl.INSM_ID,
adj.PL_POSN_ID , adj.DLY_ACCRETION_INV_AMT FROM /PnLPosition4 pnl ,
/AdjustmentPosition4 adj where adj.PL_POSN_ID = pnl.PL_POSN_ID
{noformat}
Using a function that does:
{noformat}
QueryService queryService = CacheFactory.getAnyInstance().getQueryService();
Query query = queryService.newQuery(queryStr);
SelectResults results = (SelectResults) query.execute(rfc);
context.getResultSender().lastResult(results);
{noformat}
Causes one of two exceptions when the CumulativeNonDistinctResults is
deserialized.
Either an IllegalArgumentException on the client like:
{noformat}
Caused by: java.lang.IllegalArgumentException: unexpected typeCode: 46
at
org.apache.geode.internal.serialization.StaticSerialization.decodePrimitiveClass(StaticSerialization.java:502)
at
org.apache.geode.DataSerializer.readObjectArray(DataSerializer.java:1744)
at
org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:293)
at
org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
at
org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
{noformat}
Or an OutOfMemoryError on the server like:
{noformat}
java.lang.OutOfMemoryError: Java heap space
at java.util.ArrayList.(ArrayList.java:152)
at
org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:289)
at
org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
at
org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2508)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
{noformat}
CumulativeNonDistinctResults.toData does:
{noformat}
HeapDataOutputStream hdos = new HeapDataOutputStream(1024, null);
LongUpdater lu = hdos.reserveLong();
...
DataSerializer.writeObjectArray(fields, out);
...
lu.update(numElements);
{noformat}
NWayMergeResults.toData is broken in the same way
The fix is to write the fields to hdos instead of out like:
{noformat}
DataSerializer.writeObjectArray(fields, hdos);
{noformat}
A work-around in the function is to convert the CumulativeNonDistinctResults to
a List like:
{noformat}
context.getResultSender().lastResult(results.asList());
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7957) Serializing and deserializing a CumulativeNonDistinctResults containing Structs fails with either an OutOfMemoryError or an IllegalArgumentException
[
https://issues.apache.org/jira/browse/GEODE-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby updated GEODE-7957:
---
Affects Version/s: 1.12.0
> Serializing and deserializing a CumulativeNonDistinctResults containing
> Structs fails with either an OutOfMemoryError or an IllegalArgumentException
>
>
> Key: GEODE-7957
> URL: https://issues.apache.org/jira/browse/GEODE-7957
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Barrett Oglesby
>Priority: Major
>
> Executing a query like:
> {noformat}
> SELECT pnl.TM_ID, pnl.PTD_ACCRETION_INV_AMT, pnl.FIRM_ACCT_ID, pnl.INSM_ID,
> adj.PL_POSN_ID , adj.DLY_ACCRETION_INV_AMT FROM /PnLPosition4 pnl ,
> /AdjustmentPosition4 adj where adj.PL_POSN_ID = pnl.PL_POSN_ID
> {noformat}
> Using a function that does:
> {noformat}
> QueryService queryService = CacheFactory.getAnyInstance().getQueryService();
> Query query = queryService.newQuery(queryStr);
> SelectResults results = (SelectResults) query.execute(rfc);
> context.getResultSender().lastResult(results);
> {noformat}
> Causes one of two exceptions when the CumulativeNonDistinctResults is
> deserialized.
> Either an IllegalArgumentException on the client like:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: unexpected typeCode: 46
> at
> org.apache.geode.internal.serialization.StaticSerialization.decodePrimitiveClass(StaticSerialization.java:502)
> at
> org.apache.geode.DataSerializer.readObjectArray(DataSerializer.java:1744)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:293)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> {noformat}
> Or an OutOfMemoryError on the server like:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.ArrayList.(ArrayList.java:152)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:289)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2508)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> {noformat}
> CumulativeNonDistinctResults.toData does:
> {noformat}
> HeapDataOutputStream hdos = new HeapDataOutputStream(1024, null);
> LongUpdater lu = hdos.reserveLong();
> ...
> DataSerializer.writeObjectArray(fields, out);
> ...
> lu.update(numElements);
> {noformat}
> NWayMergeResults.toData is broken in the same way
> The fix is to write the fields to hdos instead of out like:
> {noformat}
> DataSerializer.writeObjectArray(fields, hdos);
> {noformat}
> A work-around in the function is to convert the CumulativeNonDistinctResults
> to a List like:
> {noformat}
> context.getResultSender().lastResult(results.asList());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7957) Serializing and deserializing a CumulativeNonDistinctResults containing Structs fails with either an OutOfMemoryError or an IllegalArgumentException
[
https://issues.apache.org/jira/browse/GEODE-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-7957:
---
Labels: GeodeCommons (was: )
> Serializing and deserializing a CumulativeNonDistinctResults containing
> Structs fails with either an OutOfMemoryError or an IllegalArgumentException
>
>
> Key: GEODE-7957
> URL: https://issues.apache.org/jira/browse/GEODE-7957
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Barrett Oglesby
>Priority: Major
> Labels: GeodeCommons
>
> Executing a query like:
> {noformat}
> SELECT pnl.TM_ID, pnl.PTD_ACCRETION_INV_AMT, pnl.FIRM_ACCT_ID, pnl.INSM_ID,
> adj.PL_POSN_ID , adj.DLY_ACCRETION_INV_AMT FROM /PnLPosition4 pnl ,
> /AdjustmentPosition4 adj where adj.PL_POSN_ID = pnl.PL_POSN_ID
> {noformat}
> Using a function that does:
> {noformat}
> QueryService queryService = CacheFactory.getAnyInstance().getQueryService();
> Query query = queryService.newQuery(queryStr);
> SelectResults results = (SelectResults) query.execute(rfc);
> context.getResultSender().lastResult(results);
> {noformat}
> Causes one of two exceptions when the CumulativeNonDistinctResults is
> deserialized.
> Either an IllegalArgumentException on the client like:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: unexpected typeCode: 46
> at
> org.apache.geode.internal.serialization.StaticSerialization.decodePrimitiveClass(StaticSerialization.java:502)
> at
> org.apache.geode.DataSerializer.readObjectArray(DataSerializer.java:1744)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:293)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> {noformat}
> Or an OutOfMemoryError on the server like:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.ArrayList.(ArrayList.java:152)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:289)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2508)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> {noformat}
> CumulativeNonDistinctResults.toData does:
> {noformat}
> HeapDataOutputStream hdos = new HeapDataOutputStream(1024, null);
> LongUpdater lu = hdos.reserveLong();
> ...
> DataSerializer.writeObjectArray(fields, out);
> ...
> lu.update(numElements);
> {noformat}
> NWayMergeResults.toData is broken in the same way
> The fix is to write the fields to hdos instead of out like:
> {noformat}
> DataSerializer.writeObjectArray(fields, hdos);
> {noformat}
> A work-around in the function is to convert the CumulativeNonDistinctResults
> to a List like:
> {noformat}
> context.getResultSender().lastResult(results.asList());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076624#comment-17076624
]
Donal Evans commented on GEODE-7954:
{quote}Do this mean if redundancy is configured for 2 redundant copies, restore
redundancy command would return successfully if there is only one redundant
copy in the cluster?
{quote}
The command will return success status, yes. But the output will also include
information about how many regions do not have fully satisfied redundancy (if
any), so it will be clear to the user what the state of the system is.
The reasoning behind this is that as long as one redundant copy exists, we have
redundancy, although we may not have as much redundancy as we would ideally
want (if it's below the configured level), and so we have protection from data
loss in the event that we lose a member from the system. The difference between
fully satisfied redundancy (x out of x configured copies exist for each bucket)
and partially satisfied redundancy (at least 1 out of x configured copies exist
for each bucket) is much less critical than the difference between partially
satisfied redundancy and zero redundant copies existing at all, where if we
lose a member, we lose all data on that member.
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * At least one redundant copy exists for every bucket in regions with
> redundancy configured that were included, either explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not
> be reassigned during the operation. The default behaviour will be to reassign
> primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7950) Packer script for Windows uses old TLS and fails to connect
[
https://issues.apache.org/jira/browse/GEODE-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Houghton resolved GEODE-7950.
Fix Version/s: 1.13.0
Resolution: Fixed
> Packer script for Windows uses old TLS and fails to connect
> ---
>
> Key: GEODE-7950
> URL: https://issues.apache.org/jira/browse/GEODE-7950
> Project: Geode
> Issue Type: Bug
> Components: build, ci
>Reporter: Robert Houghton
>Assignee: Robert Houghton
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From Concourse:
> {code:java}
> googlecompute: WARNING: Unable to download the list of available providers.
> Check your internet connection.
> googlecompute: WARNING: Unable to download from URI
> 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
> ==> googlecompute: Install-PackageProvider : No match was found for the
> specified search criteria for the provider 'NuGet'. The package
> ==> googlecompute: provider requires 'PackageManagement' and 'Provider' tags.
> Please check if the specified package has the tags.
> ==> googlecompute: At
> C:\Windows\Temp\script-5e8b39e5-819f-74b9-9a4b-7470e3b783b6.ps1:3 char:1
> ==> googlecompute: + Install-PackageProvider -Name NuGet -MinimumVersion
> 2.8.5.201 -Force
> ==> googlecompute: +
>
> ==> googlecompute: + CategoryInfo : InvalidArgument:
> (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
> ==> googlecompute:kageProvider], Exception
> ==> googlecompute: + FullyQualifiedErrorId :
> NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
> ==> googlecompute:vider
> ==> googlecompute:
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7950) Packer script for Windows uses old TLS and fails to connect
[
https://issues.apache.org/jira/browse/GEODE-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076632#comment-17076632
]
ASF subversion and git services commented on GEODE-7950:
Commit e7f6faf637fc77daa1ca4bd942be0c10e9577dc7 in geode's branch
refs/heads/develop from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e7f6faf ]
GEODE-7950: Force TLS1.2 for installing PackageProvider=NuGet (#4908)
Would be nice to set the default TLS for all PowerShell sessions, but
that seems to be unsupported.
> Packer script for Windows uses old TLS and fails to connect
> ---
>
> Key: GEODE-7950
> URL: https://issues.apache.org/jira/browse/GEODE-7950
> Project: Geode
> Issue Type: Bug
> Components: build, ci
>Reporter: Robert Houghton
>Assignee: Robert Houghton
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From Concourse:
> {code:java}
> googlecompute: WARNING: Unable to download the list of available providers.
> Check your internet connection.
> googlecompute: WARNING: Unable to download from URI
> 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
> ==> googlecompute: Install-PackageProvider : No match was found for the
> specified search criteria for the provider 'NuGet'. The package
> ==> googlecompute: provider requires 'PackageManagement' and 'Provider' tags.
> Please check if the specified package has the tags.
> ==> googlecompute: At
> C:\Windows\Temp\script-5e8b39e5-819f-74b9-9a4b-7470e3b783b6.ps1:3 char:1
> ==> googlecompute: + Install-PackageProvider -Name NuGet -MinimumVersion
> 2.8.5.201 -Force
> ==> googlecompute: +
>
> ==> googlecompute: + CategoryInfo : InvalidArgument:
> (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
> ==> googlecompute:kageProvider], Exception
> ==> googlecompute: + FullyQualifiedErrorId :
> NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
> ==> googlecompute:vider
> ==> googlecompute:
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7958) Unable to unregister keys in C# (???)
Blake Bender created GEODE-7958:
---
Summary: Unable to unregister keys in C# (???)
Key: GEODE-7958
URL: https://issues.apache.org/jira/browse/GEODE-7958
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Blake Bender
See
[https://stackoverflow.com/questions/59986098/unregisterkeys-method-not-executing-in-apache-geode-native-client].
This appears to be specific to C#, which is _very_ strange.
The branch
[https://github.com/pdxcodemonkey/geode-native/tree/registerkeys_stackoverflow_question]
contains a test case in /clicache/integration-test2/RegisterKeysTest.cs called
RegisterUnregisterAndTest that demonstrates the bug. This assert on line 127:
{code:java}
Assert.Equal(stillInterested.Count, 0); {code}
fails with stillInterested.Count == 1, so the key registered was not
unregistered successfully. Additionally, this assert on line 135:
{code:java}
Assert.Equal(listener.UpdateCount, 3); {code}
fails after updating the value associated with the registered key again, so not
only does the client think the key is still registered, it is still sending
notifications for the key.
Repro:
i. On a Windows machine, checkout the branch above and build the native client
ii. Run RegisterKeysTest.RegisterUnregisterAndTest in
/clicache/integration-test2
Expected result:
test passes
Actual result:
test fails on the two asserts described above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076679#comment-17076679
]
Eric Shu commented on GEODE-7954:
-
User might want to wait until the full redundancy level is satisfied. Is it
possible that we could supply this information as well e.g. user can stop
members to the extents of the redundancy level for maintenance etc.
Have an extra option set so that the command only returns successful when full
redundancy level is satisfied. This can allow user to determine which command
they should be using.
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * At least one redundant copy exists for every bucket in regions with
> redundancy configured that were included, either explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not
> be reassigned during the operation. The default behaviour will be to reassign
> primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076689#comment-17076689
]
Jinmei Liao commented on GEODE-7710:
this failed again today:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/22#A
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7156) support token based authentication in management rest api
[ https://issues.apache.org/jira/browse/GEODE-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076690#comment-17076690 ] ASF subversion and git services commented on GEODE-7156: Commit d2f18fdebbeabe32bbbcfc6a71b3e6438f8b32be in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d2f18fd ] GEODE-7156: add docs for security-auth-token-enabled-components (#4910) Edit for style, clarify default > support token based authentication in management rest api > - > > Key: GEODE-7156 > URL: https://issues.apache.org/jira/browse/GEODE-7156 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > Why > to support securities needs of customers, we need to provide token access. > WHAT (for current plan) > support access token in REST API > NOT To-Do > don't break the support of username/passwd in REST API for GEODE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076697#comment-17076697
]
Donal Evans commented on GEODE-7954:
It will be possible for a user to determine if full redundancy has been
satisfied by looking at the result of the command. If the command returns
success and there is no info section for members with partially satisfied
redundancy, then they know that all included regions have fully satisfied
redundancy.
As a side note, it would have been better timing if this feedback had been
provided during the RFC discussion process, since that's where the design
details were intended to be hammered out and agreed on. Changes can be made, of
course, but there is already consensus on the proposed design at this point.
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * At least one redundant copy exists for every bucket in regions with
> redundancy configured that were included, either explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not
> be reassigned during the operation. The default behaviour will be to reassign
> primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7959) Improve ConcurrentTestRunner in heavily loaded environment
[ https://issues.apache.org/jira/browse/GEODE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7959: - Component/s: tests > Improve ConcurrentTestRunner in heavily loaded environment > -- > > Key: GEODE-7959 > URL: https://issues.apache.org/jira/browse/GEODE-7959 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Priority: Major > > Upgrading to Mockito 3.x seems to have trouble with tests using > ConcurrentTestRunner. The result is many threads trying to capture thread > stacks in invocation of mock methods. > Review of code in ConcurrentTestRunner and LoopRunner shows reveals some > issues we should improve: > * LoopRunner.execute has a hot busy while loop > * the inner for-loop of LoopRunner.runTestMethod eats exceptions without > reporting them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7959) Improve ConcurrentTestRunner in heavily loaded environment
[ https://issues.apache.org/jira/browse/GEODE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-7959: Assignee: Kirk Lund > Improve ConcurrentTestRunner in heavily loaded environment > -- > > Key: GEODE-7959 > URL: https://issues.apache.org/jira/browse/GEODE-7959 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Upgrading to Mockito 3.x seems to have trouble with tests using > ConcurrentTestRunner. The result is many threads trying to capture thread > stacks in invocation of mock methods. > Review of code in ConcurrentTestRunner and LoopRunner shows reveals some > issues we should improve: > * LoopRunner.execute has a hot busy while loop > * the inner for-loop of LoopRunner.runTestMethod eats exceptions without > reporting them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7959) Improve ConcurrentTestRunner in heavily loaded environment
Kirk Lund created GEODE-7959: Summary: Improve ConcurrentTestRunner in heavily loaded environment Key: GEODE-7959 URL: https://issues.apache.org/jira/browse/GEODE-7959 Project: Geode Issue Type: Improvement Reporter: Kirk Lund Upgrading to Mockito 3.x seems to have trouble with tests using ConcurrentTestRunner. The result is many threads trying to capture thread stacks in invocation of mock methods. Review of code in ConcurrentTestRunner and LoopRunner shows reveals some issues we should improve: * LoopRunner.execute has a hot busy while loop * the inner for-loop of LoopRunner.runTestMethod eats exceptions without reporting them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076716#comment-17076716 ] ASF subversion and git services commented on GEODE-7864: Commit d663864e720f354c374139bbdcbcc1f9fdd5eb83 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d663864 ] GEODE-7864: Remove null checks that are not required Part-2. (#4881) > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 11h 40m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076717#comment-17076717 ] ASF subversion and git services commented on GEODE-7864: Commit d4b7c1459c10ed1934080ef4a398b9d6232cfb45 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d4b7c14 ] GEODE-7864: Closing the query statements after execution. (#4873) > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 11h 50m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7960) CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion FAILED on Windows
Jinmei Liao created GEODE-7960: -- Summary: CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion FAILED on Windows Key: GEODE-7960 URL: https://issues.apache.org/jira/browse/GEODE-7960 Project: Geode Issue Type: Bug Components: logging Reporter: Jinmei Liao Looks like a flaky test on windows: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/21 org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest > logsMissingChildRegionUntilCompletion FAILED org.mockito.exceptions.verification.NoInteractionsWanted: No interactions wanted here: -> at org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180) But found this interaction on mock 'consumer': -> at org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229) *** For your reference, here is the list of all invocations ([?] - means unverified). 1. -> at org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229) 2. [?]-> at org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229) at org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7959) Improve ConcurrentTestRunner in heavily loaded environment
[ https://issues.apache.org/jira/browse/GEODE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7959: - Description: Upgrading to Mockito 3.x seems to have trouble with tests using ConcurrentTestRunner. The result is many threads stuck trying to capture thread stacks in invocation of mock methods. Review of code in ConcurrentTestRunner and LoopRunner shows reveals some issues we should improve: * LoopRunner.execute has a hot busy while loop * the inner for-loop of LoopRunner.runTestMethod eats exceptions without reporting them was: Upgrading to Mockito 3.x seems to have trouble with tests using ConcurrentTestRunner. The result is many threads trying to capture thread stacks in invocation of mock methods. Review of code in ConcurrentTestRunner and LoopRunner shows reveals some issues we should improve: * LoopRunner.execute has a hot busy while loop * the inner for-loop of LoopRunner.runTestMethod eats exceptions without reporting them > Improve ConcurrentTestRunner in heavily loaded environment > -- > > Key: GEODE-7959 > URL: https://issues.apache.org/jira/browse/GEODE-7959 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Upgrading to Mockito 3.x seems to have trouble with tests using > ConcurrentTestRunner. The result is many threads stuck trying to capture > thread stacks in invocation of mock methods. > Review of code in ConcurrentTestRunner and LoopRunner shows reveals some > issues we should improve: > * LoopRunner.execute has a hot busy while loop > * the inner for-loop of LoopRunner.runTestMethod eats exceptions without > reporting them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7947) Implement tests for EXPIRE-related functionality
[ https://issues.apache.org/jira/browse/GEODE-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076759#comment-17076759 ] ASF subversion and git services commented on GEODE-7947: Commit 1b1ad6b4c0c8d49dbbc78d20e77de12d1ff68391 in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b1ad6b ] GEODE-7947 Implement tests for EXPIRE-related functionality (#4904) * GEODE-7947 Implement tests for EXPIRE-related functionality Co-authored-by: John Hutchison Co-authored-by: Sarah > Implement tests for EXPIRE-related functionality > > > Key: GEODE-7947 > URL: https://issues.apache.org/jira/browse/GEODE-7947 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7947) Implement tests for EXPIRE-related functionality
[ https://issues.apache.org/jira/browse/GEODE-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076760#comment-17076760 ] ASF subversion and git services commented on GEODE-7947: Commit 1b1ad6b4c0c8d49dbbc78d20e77de12d1ff68391 in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1b1ad6b ] GEODE-7947 Implement tests for EXPIRE-related functionality (#4904) * GEODE-7947 Implement tests for EXPIRE-related functionality Co-authored-by: John Hutchison Co-authored-by: Sarah > Implement tests for EXPIRE-related functionality > > > Key: GEODE-7947 > URL: https://issues.apache.org/jira/browse/GEODE-7947 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7961) Add Support configure pdx commands in the new .NET test framework
Michael Martell created GEODE-7961: -- Summary: Add Support configure pdx commands in the new .NET test framework Key: GEODE-7961 URL: https://issues.apache.org/jira/browse/GEODE-7961 Project: Geode Issue Type: Improvement Components: native client Reporter: Michael Martell The current .NET Xunit test framework starts and stops the geode cluster programmatically via gfsh commands. It supports a wide range of commands, but it doesn't not provide a way to configure servers with pdx. This ticket calls for a way to insert "configure pdx ..." commands after the start locator commands and before any start server commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7962) Add support for --properties-file when starting the locators and servers
Michael Martell created GEODE-7962: -- Summary: Add support for --properties-file when starting the locators and servers Key: GEODE-7962 URL: https://issues.apache.org/jira/browse/GEODE-7962 Project: Geode Issue Type: Improvement Components: native client Reporter: Michael Martell The new .NET test framework does not support passing a --properties-file parameter to the start locator and start server commands. We need to add this functionality to allow setting the server log-level among other things. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7930) Endpoint name truncated when exceeds 99 characters causing failed connections
[
https://issues.apache.org/jira/browse/GEODE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076931#comment-17076931
]
ASF subversion and git services commented on GEODE-7930:
Commit 2e0fe622e5465b712fca3ebc2c5a0ae4883a02f7 in geode-native's branch
refs/heads/develop from jvarenina
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2e0fe62 ]
GEODE-7930: Fix endpoint name truncation bug
- Removed truncation of endpoint when exceedes 99 chars
- Also, fixed wrong logging of error when endpoint is successfully
added to the pool
> Endpoint name truncated when exceeds 99 characters causing failed connections
> -
>
> Key: GEODE-7930
> URL: https://issues.apache.org/jira/browse/GEODE-7930
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: locator.log, native_client_error.log, server.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When subscription is "enabled" in native client then the server endpoint name
> (host name + port) is truncated if exceeds 99 characters resulting with
> failed connections towards servers (see logs in attachment). When
> subscription is "disabled" everything worked fine for what I tested. Also I
> performed some tests with java client and haven't found such limitation on
> endpoint name length.
> Endpoint name (e.g. server host name) + port is truncated within function
> addEP:
> {code:cpp}
> TcrEndpoint* ThinClientPoolDM::addEP(ServerLocation& serverLoc) {
> std::string serverName = serverLoc.getServerName();
> int port = serverLoc.getPort();
> char endpointName[100];
> std::snprintf(endpointName, 100, "%s:%d", serverName.c_str(), port);
> return addEP(endpointName);
> }
> {code}
> Maximum length of FQDN according to RFC 2181:
> _The DNS itself places only one restriction on the particular labels_
> _that can be used to identify resource records. That one restriction_
> _relates to the length of the label and the full name. The length of_
> _any one label is limited to between 1 and 63 octets. A full domain_
> _name is limited to 255 octets (including the separators)._
> Due to above requirement the function addEP should not limit or truncate
> endpoint name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7930) Endpoint name truncated when exceeds 99 characters causing failed connections
[
https://issues.apache.org/jira/browse/GEODE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076932#comment-17076932
]
ASF subversion and git services commented on GEODE-7930:
Commit 7dbcae083af718d02d9284c5a4a221badc34e226 in geode-native's branch
refs/heads/develop from Mario Kevo
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7dbcae0 ]
Merge pull request #588 from Nordix/feature/GEODE-7930
GEODE-7930: Fix endpoint name truncation bug
> Endpoint name truncated when exceeds 99 characters causing failed connections
> -
>
> Key: GEODE-7930
> URL: https://issues.apache.org/jira/browse/GEODE-7930
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: locator.log, native_client_error.log, server.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When subscription is "enabled" in native client then the server endpoint name
> (host name + port) is truncated if exceeds 99 characters resulting with
> failed connections towards servers (see logs in attachment). When
> subscription is "disabled" everything worked fine for what I tested. Also I
> performed some tests with java client and haven't found such limitation on
> endpoint name length.
> Endpoint name (e.g. server host name) + port is truncated within function
> addEP:
> {code:cpp}
> TcrEndpoint* ThinClientPoolDM::addEP(ServerLocation& serverLoc) {
> std::string serverName = serverLoc.getServerName();
> int port = serverLoc.getPort();
> char endpointName[100];
> std::snprintf(endpointName, 100, "%s:%d", serverName.c_str(), port);
> return addEP(endpointName);
> }
> {code}
> Maximum length of FQDN according to RFC 2181:
> _The DNS itself places only one restriction on the particular labels_
> _that can be used to identify resource records. That one restriction_
> _relates to the length of the label and the full name. The length of_
> _any one label is limited to between 1 and 63 octets. A full domain_
> _name is limited to 255 octets (including the separators)._
> Due to above requirement the function addEP should not limit or truncate
> endpoint name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7930) Endpoint name truncated when exceeds 99 characters causing failed connections
[
https://issues.apache.org/jira/browse/GEODE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076933#comment-17076933
]
ASF subversion and git services commented on GEODE-7930:
Commit 7dbcae083af718d02d9284c5a4a221badc34e226 in geode-native's branch
refs/heads/develop from Mario Kevo
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7dbcae0 ]
Merge pull request #588 from Nordix/feature/GEODE-7930
GEODE-7930: Fix endpoint name truncation bug
> Endpoint name truncated when exceeds 99 characters causing failed connections
> -
>
> Key: GEODE-7930
> URL: https://issues.apache.org/jira/browse/GEODE-7930
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: locator.log, native_client_error.log, server.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When subscription is "enabled" in native client then the server endpoint name
> (host name + port) is truncated if exceeds 99 characters resulting with
> failed connections towards servers (see logs in attachment). When
> subscription is "disabled" everything worked fine for what I tested. Also I
> performed some tests with java client and haven't found such limitation on
> endpoint name length.
> Endpoint name (e.g. server host name) + port is truncated within function
> addEP:
> {code:cpp}
> TcrEndpoint* ThinClientPoolDM::addEP(ServerLocation& serverLoc) {
> std::string serverName = serverLoc.getServerName();
> int port = serverLoc.getPort();
> char endpointName[100];
> std::snprintf(endpointName, 100, "%s:%d", serverName.c_str(), port);
> return addEP(endpointName);
> }
> {code}
> Maximum length of FQDN according to RFC 2181:
> _The DNS itself places only one restriction on the particular labels_
> _that can be used to identify resource records. That one restriction_
> _relates to the length of the label and the full name. The length of_
> _any one label is limited to between 1 and 63 octets. A full domain_
> _name is limited to 255 octets (including the separators)._
> Due to above requirement the function addEP should not limit or truncate
> endpoint name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7963) Total bucket and total priamry bucket count per server is incorrect
Mario Kevo created GEODE-7963: - Summary: Total bucket and total priamry bucket count per server is incorrect Key: GEODE-7963 URL: https://issues.apache.org/jira/browse/GEODE-7963 Project: Geode Issue Type: Bug Components: gfsh, statistics Reporter: Mario Kevo Attachments: showMetricsCommand.txt If we have more buckets per region than default value is_, show metrics_ command per server has wrong stats for *totalBucketCount* and *totalPrimaryCount*. Number of buckets is good if _show metric_s is executed region by region per server. It looks like it doesn't take last updated results when print output. After last bucket are created it increase these two values but in output we have a value before that increase. To reproduce an issue: # Run locator and 4 servers. # create partition persistent region with total-num-buckets more than default value # do query (_query --query="select * from /region1"_) # Repeat steps 2. and 3. to create and query more regions # see result of show metrics per server and region by region per server -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7963) Total bucket and total primary bucket count per server is incorrect
[ https://issues.apache.org/jira/browse/GEODE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-7963: -- Attachment: showMetricsCommand.txt > Total bucket and total primary bucket count per server is incorrect > --- > > Key: GEODE-7963 > URL: https://issues.apache.org/jira/browse/GEODE-7963 > Project: Geode > Issue Type: Bug > Components: gfsh, statistics >Reporter: Mario Kevo >Priority: Major > Attachments: showMetricsCommand.txt > > > If we have more buckets per region than default value is_, show metrics_ > command per server has wrong stats for *totalBucketCount* and > *totalPrimaryCount*. Number of buckets is good if _show metric_s is executed > region by region per server. > It looks like it doesn't take last updated results when print output. > After last bucket are created it increase these two values but in output we > have a value before that increase. > To reproduce an issue: > # Run locator and 4 servers. > # create partition persistent region with total-num-buckets more than > default value > # do query (_query --query="select * from /region1"_) > # Repeat steps 2. and 3. to create and query more regions > # see result of show metrics per server and region by region per server -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7963) Total bucket and total primary bucket count per server is incorrect
[ https://issues.apache.org/jira/browse/GEODE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-7963: -- Summary: Total bucket and total primary bucket count per server is incorrect (was: Total bucket and total priamry bucket count per server is incorrect) > Total bucket and total primary bucket count per server is incorrect > --- > > Key: GEODE-7963 > URL: https://issues.apache.org/jira/browse/GEODE-7963 > Project: Geode > Issue Type: Bug > Components: gfsh, statistics >Reporter: Mario Kevo >Priority: Major > Attachments: showMetricsCommand.txt > > > If we have more buckets per region than default value is_, show metrics_ > command per server has wrong stats for *totalBucketCount* and > *totalPrimaryCount*. Number of buckets is good if _show metric_s is executed > region by region per server. > It looks like it doesn't take last updated results when print output. > After last bucket are created it increase these two values but in output we > have a value before that increase. > To reproduce an issue: > # Run locator and 4 servers. > # create partition persistent region with total-num-buckets more than > default value > # do query (_query --query="select * from /region1"_) > # Repeat steps 2. and 3. to create and query more regions > # see result of show metrics per server and region by region per server -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7963) Total bucket and total primary bucket count per server is incorrect
[ https://issues.apache.org/jira/browse/GEODE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-7963: - Assignee: Mario Kevo > Total bucket and total primary bucket count per server is incorrect > --- > > Key: GEODE-7963 > URL: https://issues.apache.org/jira/browse/GEODE-7963 > Project: Geode > Issue Type: Bug > Components: gfsh, statistics >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Attachments: showMetricsCommand.txt > > > If we have more buckets per region than default value is_, show metrics_ > command per server has wrong stats for *totalBucketCount* and > *totalPrimaryCount*. Number of buckets is good if _show metric_s is executed > region by region per server. > It looks like it doesn't take last updated results when print output. > After last bucket are created it increase these two values but in output we > have a value before that increase. > To reproduce an issue: > # Run locator and 4 servers. > # create partition persistent region with total-num-buckets more than > default value > # do query (_query --query="select * from /region1"_) > # Repeat steps 2. and 3. to create and query more regions > # see result of show metrics per server and region by region per server -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7930) Endpoint name truncated when exceeds 99 characters causing failed connections
[
https://issues.apache.org/jira/browse/GEODE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina resolved GEODE-7930.
---
Fix Version/s: 1.13.0
Resolution: Fixed
> Endpoint name truncated when exceeds 99 characters causing failed connections
> -
>
> Key: GEODE-7930
> URL: https://issues.apache.org/jira/browse/GEODE-7930
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Fix For: 1.13.0
>
> Attachments: locator.log, native_client_error.log, server.log
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When subscription is "enabled" in native client then the server endpoint name
> (host name + port) is truncated if exceeds 99 characters resulting with
> failed connections towards servers (see logs in attachment). When
> subscription is "disabled" everything worked fine for what I tested. Also I
> performed some tests with java client and haven't found such limitation on
> endpoint name length.
> Endpoint name (e.g. server host name) + port is truncated within function
> addEP:
> {code:cpp}
> TcrEndpoint* ThinClientPoolDM::addEP(ServerLocation& serverLoc) {
> std::string serverName = serverLoc.getServerName();
> int port = serverLoc.getPort();
> char endpointName[100];
> std::snprintf(endpointName, 100, "%s:%d", serverName.c_str(), port);
> return addEP(endpointName);
> }
> {code}
> Maximum length of FQDN according to RFC 2181:
> _The DNS itself places only one restriction on the particular labels_
> _that can be used to identify resource records. That one restriction_
> _relates to the length of the label and the full name. The length of_
> _any one label is limited to between 1 and 63 octets. A full domain_
> _name is limited to 255 octets (including the separators)._
> Due to above requirement the function addEP should not limit or truncate
> endpoint name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
