[jira] [Resolved] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar resolved GEODE-3445.
-
Resolution: Fixed
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201475#comment-16201475
]
ASF subversion and git services commented on GEODE-3445:
Commit 840847b379dbb89568b80a8c3f7ac5830dd5ef82 in geode's branch
refs/heads/develop from [~karensmolermiller]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=840847b ]
GEODE-3445 Revise doc to specify 1-way authentication
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201477#comment-16201477
]
ASF subversion and git services commented on GEODE-3445:
Commit 0768f93733555140158457a59a7ce0e15763976d in geode's branch
refs/heads/develop from [~swapnil.bawaskar]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0768f93 ]
Merge pull request #913 from karensmolermiller/feature/GEODE-3445
GEODE-3445 Document new gfsh connect option
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201476#comment-16201476
]
ASF subversion and git services commented on GEODE-3445:
Commit 0768f93733555140158457a59a7ce0e15763976d in geode's branch
refs/heads/develop from [~swapnil.bawaskar]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0768f93 ]
Merge pull request #913 from karensmolermiller/feature/GEODE-3445
GEODE-3445 Document new gfsh connect option
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201474#comment-16201474
]
ASF subversion and git services commented on GEODE-3445:
Commit 29a2e9f6696a2f2e5ea54117355c2048e918c4ea in geode's branch
refs/heads/develop from [~karensmolermiller]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=29a2e9f ]
GEODE-3445 Document new gfsh connect option
- Documented the new --skip-ssl-validation option
- Added newline characters to eliminate horizontal
scroll bars within the web page
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3805) CacheStatisticsDUnitTest failure due to delta in timestamp
[ https://issues.apache.org/jira/browse/GEODE-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich resolved GEODE-3805. --- Resolution: Fixed Fix Version/s: 1.3.0 > CacheStatisticsDUnitTest failure due to delta in timestamp > -- > > Key: GEODE-3805 > URL: https://issues.apache.org/jira/browse/GEODE-3805 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Nick Reich >Assignee: Nick Reich > Fix For: 1.3.0 > > > Checking the accuracy of the last modified time can fail because the last > accessed time is being used as a comparison for the last modified time. These > values will normally be the same, but they are determined separately in time, > allowing for there to be a discrepancy in their values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3791) Improve test coverage of CacheListener for PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-3791. -- Resolution: Fixed Fix Version/s: 1.3.0 > Improve test coverage of CacheListener for PartitionedRegion > > > Key: GEODE-3791 > URL: https://issues.apache.org/jira/browse/GEODE-3791 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund > Fix For: 1.3.0 > > > Verify CacheListener is invoked for all Region operations only in the bucket > primary which has registered a CacheListener for the Region. > There is a hidden system property to enable callbacks within secondaries. A > test should also be written to cover that as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3805) CacheStatisticsDUnitTest failure due to delta in timestamp
[ https://issues.apache.org/jira/browse/GEODE-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201207#comment-16201207 ] ASF subversion and git services commented on GEODE-3805: Commit 475d5d5f420acbbf360699b75e023c41f77a267b in geode's branch refs/heads/develop from [~nreich] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=475d5d5 ] GEODE-3805: Use correct timestamplto check last modified time > CacheStatisticsDUnitTest failure due to delta in timestamp > -- > > Key: GEODE-3805 > URL: https://issues.apache.org/jira/browse/GEODE-3805 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Nick Reich >Assignee: Nick Reich > > Checking the accuracy of the last modified time can fail because the last > accessed time is being used as a comparison for the last modified time. These > values will normally be the same, but they are determined separately in time, > allowing for there to be a discrepancy in their values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3791) Improve test coverage of CacheListener for PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201202#comment-16201202 ] ASF subversion and git services commented on GEODE-3791: Commit e4cadc35e35d22736008e5e13c6aa334f5a94d3d in geode's branch refs/heads/develop from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4cadc3 ] GEODE-3791: add new tests for CacheListener on PartionedRegion > Improve test coverage of CacheListener for PartitionedRegion > > > Key: GEODE-3791 > URL: https://issues.apache.org/jira/browse/GEODE-3791 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund > > Verify CacheListener is invoked for all Region operations only in the bucket > primary which has registered a CacheListener for the Region. > There is a hidden system property to enable callbacks within secondaries. A > test should also be written to cover that as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3813) Region registerInterest API usage of type parameters is broken
[
https://issues.apache.org/jira/browse/GEODE-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-3813:
-
Description:
The registerInterest API works for single key registration but is broken for
all other types of registration if the Region is declared with type parameters:
Single key (works):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1);
{noformat}
ALL_KEYS token is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest("ALL_KEYS");
{noformat}
List of keys is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
List listOfKeys = new ArrayList<>();
listOfKeys.add(1);
listOfKeys.add(2);
region.registerInterest(listOfKeys);
{noformat}
When this ticket is fixed and the API is updated, we should consider adding
support for var args:
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1, 2, 3);
{noformat}
was:
The registerInterest API works for single key registration but is broken for
all other types of registration if the Region is declared with type parameters:
Single key (works):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1);
{noformat}
ALL_KEYS token is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest("ALL_KEYS");
{noformat}
List of keys is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
List listOfKeys = new ArrayList<>();
listOfKeys.add(1);
listOfKeys.add(2);
region.registerInterest(listOfKeys);
{noformat}
When this ticket is fixed and the API is updated, we should consider adding
support var args:
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1, 2, 3);
{noformat}
> Region registerInterest API usage of type parameters is broken
> --
>
> Key: GEODE-3813
> URL: https://issues.apache.org/jira/browse/GEODE-3813
> Project: Geode
> Issue Type: Bug
> Components: client queues, regions
>Reporter: Kirk Lund
>
> The registerInterest API works for single key registration but is broken for
> all other types of registration if the Region is declared with type
> parameters:
> Single key (works):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1);
> {noformat}
> ALL_KEYS token is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest("ALL_KEYS");
> {noformat}
> List of keys is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> List listOfKeys = new ArrayList<>();
> listOfKeys.add(1);
> listOfKeys.add(2);
> region.registerInterest(listOfKeys);
> {noformat}
> When this ticket is fixed and the API is updated, we should consider adding
> support for var args:
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1, 2, 3);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201167#comment-16201167 ] ASF subversion and git services commented on GEODE-3780: Commit 4d0ef238bceecb995a0e8b1fa9501cc5908c9810 in geode's branch refs/heads/feature/GEODE-3780b from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4d0ef23 ] GEODE-3780 suspected member is never watched again after passing final check spotless > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201123#comment-16201123 ] ASF subversion and git services commented on GEODE-3780: Commit ad6eff1a0a6ca9700587d5291e9a3fb2e5cee87a in geode's branch refs/heads/feature/GEODE-3780b from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad6eff1 ] GEODE-3780 suspected member is never watched again after passing final check and git bit me again - this contains the content of the new message and the handling of it. > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201113#comment-16201113 ] ASF subversion and git services commented on GEODE-3780: Commit 5214474f63737648922a32e9778a33edb8128752 in geode's branch refs/heads/feature/GEODE-3780b from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5214474 ] GEODE-3780 suspected member is never watched again after passing final check removed unnecessary "GMSHealthMonitor.this" > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201114#comment-16201114 ] ASF subversion and git services commented on GEODE-3780: Commit 12416bb99ff7803e6f7d84c6038bc1995be4c1a0 in geode's branch refs/heads/feature/GEODE-3780b from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=12416bb ] GEODE-3780 suspected member is never watched again after passing final check incorporating review feedback from Hitesh. We want members other than the coordinator to also reconsider the suspected member. The Monitor will now invoke setNextNeighbor at the end of its run() method and a final check that passes will result in a message being sent to the initiator so that it can start watching the suspect again. > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (GEODE-3094) LocatorUDPSecurityDUnitTest failures
[ https://issues.apache.org/jira/browse/GEODE-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt closed GEODE-3094. --- > LocatorUDPSecurityDUnitTest failures > > > Key: GEODE-3094 > URL: https://issues.apache.org/jira/browse/GEODE-3094 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.1.0 >Reporter: Bruce Schuchardt > Attachments: locatorudpsecuritydunittest_failure.txt > > > a new test, testMultipleLocatorsRestartingWithMissingServers, fails off and > on when discovery uses GMSJoinLeave.findCoordinatorFromView() to locate the > coordinator. This appears to be due to the "registrants" set having members > whose PK isn't known. I'm attaching debug-level logs of a failed run. > This relates to GEODE-3052. Restart of locators isn't a problem if there are > servers still up - it's only when the persistent view is used during locator > startup and the view contains defunct servers, making the locator resort to > using findCoordinatorFromView(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3738) CI Failure: org.apache.geode.security.ClientAuthorizationDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt updated GEODE-3738:
Component/s: (was: client/server)
> CI Failure: org.apache.geode.security.ClientAuthorizationDUnitTest
> ---
>
> Key: GEODE-3738
> URL: https://issues.apache.org/jira/browse/GEODE-3738
> Project: Geode
> Issue Type: Bug
> Components: security, tests
>Reporter: Jared Stewart
>
> {noformat}
> Error
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthorizationDUnitTest$$Lambda$177/351125497.run
> in VM 2 running on Host 2d21656aaf6b with 4 VMs with version 120
> Stacktrace
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthorizationDUnitTest$$Lambda$177/351125497.run
> in VM 2 running on Host 2d21656aaf6b with 4 VMs with version 120
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.security.ClientAuthorizationDUnitTest.testPutsGetsWithFailover(ClientAuthorizationDUnitTest.java:350)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.GeneratedMethodAccessor443.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at
[jira] [Updated] (GEODE-3813) Region registerInterest API usage of type parameters is broken
[
https://issues.apache.org/jira/browse/GEODE-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt updated GEODE-3813:
Component/s: (was: client/server)
client queues
> Region registerInterest API usage of type parameters is broken
> --
>
> Key: GEODE-3813
> URL: https://issues.apache.org/jira/browse/GEODE-3813
> Project: Geode
> Issue Type: Bug
> Components: client queues, regions
>Reporter: Kirk Lund
>
> The registerInterest API works for single key registration but is broken for
> all other types of registration if the Region is declared with type
> parameters:
> Single key (works):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1);
> {noformat}
> ALL_KEYS token is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest("ALL_KEYS");
> {noformat}
> List of keys is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> List listOfKeys = new ArrayList<>();
> listOfKeys.add(1);
> listOfKeys.add(2);
> region.registerInterest(listOfKeys);
> {noformat}
> When this ticket is fixed and the API is updated, we should consider adding
> support var args:
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1, 2, 3);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3808) LonerDMJUnitTest.testMemberID fails if hostname lookup isn't working correctly on the host machine
[ https://issues.apache.org/jira/browse/GEODE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-3808. - Resolution: Fixed Fix Version/s: 1.3.0 > LonerDMJUnitTest.testMemberID fails if hostname lookup isn't working > correctly on the host machine > -- > > Key: GEODE-3808 > URL: https://issues.apache.org/jira/browse/GEODE-3808 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > Labels: flaky > Fix For: 1.3.0 > > > org.apache.geode.LonerDMJUnitTest.testMemberId > Failing for the past 1 build (Since Failed#979 ) > Took 33 ms. > Error Message > org.junit.ComparisonFailure: expected:<[qnode2.quenda.co]> but > was:<[172.18.0.1]> > Stacktrace > org.junit.ComparisonFailure: expected:<[qnode2.quenda.co]> but > was:<[172.18.0.1]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.LonerDMJUnitTest.testMemberId(LonerDMJUnitTest.java:173) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147) > at >
[jira] [Commented] (GEODE-3808) LonerDMJUnitTest.testMemberID fails if hostname lookup isn't working correctly on the host machine
[ https://issues.apache.org/jira/browse/GEODE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200975#comment-16200975 ] ASF subversion and git services commented on GEODE-3808: Commit cfe220869aca0b6c3a5381765f977ad37d88844e in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cfe2208 ] GEODE-3808 LonerDMJUnitTest.testMemberID fails if hostname lookup isn't working Removed host name assertions > LonerDMJUnitTest.testMemberID fails if hostname lookup isn't working > correctly on the host machine > -- > > Key: GEODE-3808 > URL: https://issues.apache.org/jira/browse/GEODE-3808 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt > Labels: flaky > > org.apache.geode.LonerDMJUnitTest.testMemberId > Failing for the past 1 build (Since Failed#979 ) > Took 33 ms. > Error Message > org.junit.ComparisonFailure: expected:<[qnode2.quenda.co]> but > was:<[172.18.0.1]> > Stacktrace > org.junit.ComparisonFailure: expected:<[qnode2.quenda.co]> but > was:<[172.18.0.1]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.LonerDMJUnitTest.testMemberId(LonerDMJUnitTest.java:173) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at >
[jira] [Resolved] (GEODE-1176) CI failure: FixedPRSinglehopDUnitTest.test_MetadataContents
[
https://issues.apache.org/jira/browse/GEODE-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-1176.
-
Resolution: Fixed
Fix Version/s: 1.2.0
This ticket was fixed when GEODE-1193 was fixed
> CI failure: FixedPRSinglehopDUnitTest.test_MetadataContents
> ---
>
> Key: GEODE-1176
> URL: https://issues.apache.org/jira/browse/GEODE-1176
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
> Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> (From Eric Shu. This is a new ticket reopening GEODE-550)
> This failed in a precheckin. Reopen this.
> Regression
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.test_MetadataContents
> Failing for the past 1 build (Since Failed#167 )
> Took 1 min 2 sec.
> (no description)
> Error Message
> java.lang.AssertionError: Event never occurred after 6 ms: expected no
> metadata to be refreshed. Expected 9 entries but found
> {0=[BucketServerLocation
> {bucketId=0,host=localhost,port=29800,isPrimary=false,version=3},
> BucketServerLocation{bucketId=0,host=localhost,port=25020,isPrimary=true,version=4}],
>
> 1=[BucketServerLocation{bucketId=1,host=localhost,port=29800,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=1,host=localhost,port=25020,isPrimary=true,version=4}],
>
> 3=[BucketServerLocation{bucketId=3,host=localhost,port=25020,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=3,host=localhost,port=27409,isPrimary=true,version=4}],
>
> 4=[BucketServerLocation{bucketId=4,host=localhost,port=25020,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=4,host=localhost,port=27409,isPrimary=true,version=4}],
>
> 6=[BucketServerLocation{bucketId=6,host=localhost,port=27409,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=6,host=localhost,port=29281,isPrimary=true,version=5}],
>
> 9=[BucketServerLocation{bucketId=9,host=localhost,port=29800,isPrimary=true,version=5},
>
> BucketServerLocation{bucketId=9,host=localhost,port=29281,isPrimary=false,version=3}],
>
> 11=[BucketServerLocation{bucketId=11,host=localhost,port=29800,isPrimary=true,version=5},
>
> BucketServerLocation{bucketId=11,host=localhost,port=29281,isPrimary=false,version=3}]}
> Stacktrace
> java.lang.AssertionError: Event never occurred after 6 ms: expected no
> metadata to be refreshed. Expected 9 entries but found
> {0=[BucketServerLocation{bucketId=0,host=localhost,port=29800,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=0,host=localhost,port=25020,isPrimary=true,version=4}
> ], 1=[BucketServerLocation
> {bucketId=1,host=localhost,port=29800,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=1,host=localhost,port=25020,isPrimary=true,version=4}
> ], 3=[BucketServerLocation
> {bucketId=3,host=localhost,port=25020,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=3,host=localhost,port=27409,isPrimary=true,version=4}
> ], 4=[BucketServerLocation
> {bucketId=4,host=localhost,port=25020,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=4,host=localhost,port=27409,isPrimary=true,version=4}
> ], 6=[BucketServerLocation
> {bucketId=6,host=localhost,port=27409,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=6,host=localhost,port=29281,isPrimary=true,version=5}
> ], 9=[BucketServerLocation
> {bucketId=9,host=localhost,port=29800,isPrimary=true,version=5}
> , BucketServerLocation
> {bucketId=9,host=localhost,port=29281,isPrimary=false,version=3}
> ], 11=[BucketServerLocation
> {bucketId=11,host=localhost,port=29800,isPrimary=true,version=5}
> , BucketServerLocation
> {bucketId=11,host=localhost,port=29281,isPrimary=false,version=3}
> ]}
> at org.junit.Assert.fail(Assert.java:88)
> at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:185)
> at
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.verifyMetadata(FixedPRSinglehopDUnitTest.java:860)
> at
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.test_MetadataContents(FixedPRSinglehopDUnitTest.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at
[jira] [Commented] (GEODE-1176) CI failure: FixedPRSinglehopDUnitTest.test_MetadataContents
[
https://issues.apache.org/jira/browse/GEODE-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200959#comment-16200959
]
ASF subversion and git services commented on GEODE-1176:
Commit 02f59cf80b3aa2829916cf0f88e001d294fb9da5 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=02f59cf ]
GEODE-1176 CI failure: FixedPRSinglehopDUnitTest.test_MetadataContents
I think Galen fixed this test when he fixed GEODE-1923. I'm removing
the FlakyTest annotation.
> CI failure: FixedPRSinglehopDUnitTest.test_MetadataContents
> ---
>
> Key: GEODE-1176
> URL: https://issues.apache.org/jira/browse/GEODE-1176
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
> Labels: CI, Flaky
>
> (From Eric Shu. This is a new ticket reopening GEODE-550)
> This failed in a precheckin. Reopen this.
> Regression
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.test_MetadataContents
> Failing for the past 1 build (Since Failed#167 )
> Took 1 min 2 sec.
> (no description)
> Error Message
> java.lang.AssertionError: Event never occurred after 6 ms: expected no
> metadata to be refreshed. Expected 9 entries but found
> {0=[BucketServerLocation
> {bucketId=0,host=localhost,port=29800,isPrimary=false,version=3},
> BucketServerLocation{bucketId=0,host=localhost,port=25020,isPrimary=true,version=4}],
>
> 1=[BucketServerLocation{bucketId=1,host=localhost,port=29800,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=1,host=localhost,port=25020,isPrimary=true,version=4}],
>
> 3=[BucketServerLocation{bucketId=3,host=localhost,port=25020,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=3,host=localhost,port=27409,isPrimary=true,version=4}],
>
> 4=[BucketServerLocation{bucketId=4,host=localhost,port=25020,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=4,host=localhost,port=27409,isPrimary=true,version=4}],
>
> 6=[BucketServerLocation{bucketId=6,host=localhost,port=27409,isPrimary=false,version=3},
>
> BucketServerLocation{bucketId=6,host=localhost,port=29281,isPrimary=true,version=5}],
>
> 9=[BucketServerLocation{bucketId=9,host=localhost,port=29800,isPrimary=true,version=5},
>
> BucketServerLocation{bucketId=9,host=localhost,port=29281,isPrimary=false,version=3}],
>
> 11=[BucketServerLocation{bucketId=11,host=localhost,port=29800,isPrimary=true,version=5},
>
> BucketServerLocation{bucketId=11,host=localhost,port=29281,isPrimary=false,version=3}]}
> Stacktrace
> java.lang.AssertionError: Event never occurred after 6 ms: expected no
> metadata to be refreshed. Expected 9 entries but found
> {0=[BucketServerLocation{bucketId=0,host=localhost,port=29800,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=0,host=localhost,port=25020,isPrimary=true,version=4}
> ], 1=[BucketServerLocation
> {bucketId=1,host=localhost,port=29800,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=1,host=localhost,port=25020,isPrimary=true,version=4}
> ], 3=[BucketServerLocation
> {bucketId=3,host=localhost,port=25020,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=3,host=localhost,port=27409,isPrimary=true,version=4}
> ], 4=[BucketServerLocation
> {bucketId=4,host=localhost,port=25020,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=4,host=localhost,port=27409,isPrimary=true,version=4}
> ], 6=[BucketServerLocation
> {bucketId=6,host=localhost,port=27409,isPrimary=false,version=3}
> , BucketServerLocation
> {bucketId=6,host=localhost,port=29281,isPrimary=true,version=5}
> ], 9=[BucketServerLocation
> {bucketId=9,host=localhost,port=29800,isPrimary=true,version=5}
> , BucketServerLocation
> {bucketId=9,host=localhost,port=29281,isPrimary=false,version=3}
> ], 11=[BucketServerLocation
> {bucketId=11,host=localhost,port=29800,isPrimary=true,version=5}
> , BucketServerLocation
> {bucketId=11,host=localhost,port=29281,isPrimary=false,version=3}
> ]}
> at org.junit.Assert.fail(Assert.java:88)
> at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:185)
> at
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.verifyMetadata(FixedPRSinglehopDUnitTest.java:860)
> at
> com.gemstone.gemfire.internal.cache.FixedPRSinglehopDUnitTest.test_MetadataContents(FixedPRSinglehopDUnitTest.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
[jira] [Resolved] (GEODE-3803) Add common string methods to whitelisted methods
[ https://issues.apache.org/jira/browse/GEODE-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-3803. Resolution: Fixed > Add common string methods to whitelisted methods > > > Key: GEODE-3803 > URL: https://issues.apache.org/jira/browse/GEODE-3803 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh > Fix For: 1.3.0 > > > With GEODE-3247 we are now explicitly allowing a list of white listed methods > with oql queries when security is enabled. > Common string methods should probably be added to this whitelist, such as > startsWith, endsWith, matches, etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3685) MBean wrappers are not always applied correctly
[ https://issues.apache.org/jira/browse/GEODE-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200939#comment-16200939 ] ASF subversion and git services commented on GEODE-3685: Commit f6390a76d027ffcbea7c22a97c6ef582734cf8b8 in geode's branch refs/heads/develop from [~jstewart] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6390a7 ] GEODE-3685: Fix test failure > MBean wrappers are not always applied correctly > --- > > Key: GEODE-3685 > URL: https://issues.apache.org/jira/browse/GEODE-3685 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1 >Reporter: Jared Stewart >Assignee: Jared Stewart > Fix For: 1.3.0 > > > Under certain conditions, MBean wrappers are not applied correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3816) Have links on website Releases page open in new tab/window
Joey McAllister created GEODE-3816: -- Summary: Have links on website Releases page open in new tab/window Key: GEODE-3816 URL: https://issues.apache.org/jira/browse/GEODE-3816 Project: Geode Issue Type: Task Components: docs Reporter: Joey McAllister As a geode.apache.org reader, I want to visit a release link on the Releases page without losing my place on the Geode website or having to navigate back to it. Releases page at geode.apache.org currently open in the current window and take the reader away from the Geode website. A good suggestion from [~jblum] is to have those links open a new tab/window, so the reader remains on the Geode site in the current window. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3720) CI Failure: ConnectCommandWithSSLTest failed
[ https://issues.apache.org/jira/browse/GEODE-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-3720: --- Assignee: Kenneth Howe (was: Jinmei Liao) > CI Failure: ConnectCommandWithSSLTest failed > > > Key: GEODE-3720 > URL: https://issues.apache.org/jira/browse/GEODE-3720 > Project: Geode > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Jinmei Liao >Assignee: Kenneth Howe > > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSL(ConnectCommandWithSSLTest.java:198) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithNoSSL(ConnectCommandWithSSLTest.java:177) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterAndJmxSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterAndJmxSSL(ConnectCommandWithSSLTest.java:309) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSLAndThenWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSLAndThenWithNoSSL(ConnectCommandWithSSLTest.java:320) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithHttpSSLAndSkipSSLValidation FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithHttpSSLAndSkipSSLValidation(ConnectCommandWithSSLTest.java:286) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterSSL(ConnectCommandWithSSLTest.java:246) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithJmxSSL FAILED > java.lang.AssertionError: > Expecting: > <"_ __ >/ _/ __/ __/ // / > / / __/ /___ /_ / _ / > / /__/ / / _/ / // / > /__/_/ /__/_//_/0.0.0 > > Monitor and Manage Pivotal GemFire > Connecting to Locator at [host=localhost,
[jira] [Updated] (GEODE-3720) CI Failure: ConnectCommandWithSSLTest failed
[ https://issues.apache.org/jira/browse/GEODE-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-3720: Affects Version/s: 1.2.1 > CI Failure: ConnectCommandWithSSLTest failed > > > Key: GEODE-3720 > URL: https://issues.apache.org/jira/browse/GEODE-3720 > Project: Geode > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Jinmei Liao >Assignee: Jinmei Liao > > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSL(ConnectCommandWithSSLTest.java:198) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithNoSSL(ConnectCommandWithSSLTest.java:177) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterAndJmxSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterAndJmxSSL(ConnectCommandWithSSLTest.java:309) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSLAndThenWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSLAndThenWithNoSSL(ConnectCommandWithSSLTest.java:320) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithHttpSSLAndSkipSSLValidation FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithHttpSSLAndSkipSSLValidation(ConnectCommandWithSSLTest.java:286) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterSSL(ConnectCommandWithSSLTest.java:246) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithJmxSSL FAILED > java.lang.AssertionError: > Expecting: > <"_ __ >/ _/ __/ __/ // / > / / __/ /___ /_ / _ / > / /__/ / / _/ / // / > /__/_/ /__/_//_/0.0.0 > > Monitor and Manage Pivotal GemFire > Connecting to Locator at [host=localhost, port=34968] .. >
[jira] [Reopened] (GEODE-3720) CI Failure: ConnectCommandWithSSLTest failed
[
https://issues.apache.org/jira/browse/GEODE-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reopened GEODE-3720:
-
Some tests in this class continue to fail intermittently on precheckin and
nightly build runs. Latest case was on
https://builds.apache.org/view/All/job/Geode-nightly/980/ . As far as I can
determine, the tests have not been seen to fail when class is run be itself.
{code}
java.lang.AssertionError:
Expecting:
<"?[34m_ __
/ _/ __/ __/ // /
/ / __/ /___ /_ / _ /
/ /__/ / / _/ / // /
/__/_/ /__/_//_/1.3.0-SNAPSHOT
?[0m
?[36mMonitor and Manage Apache Geode?[0m
Connecting to Locator at [host=localhost, port=36478] ..
Connection reset
">
to contain:
<"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
at
org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithNoSSL(ConnectCommandWithSSLTest.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
{code}
> CI Failure: ConnectCommandWithSSLTest failed
>
>
> Key: GEODE-3720
> URL: https://issues.apache.org/jira/browse/GEODE-3720
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithSSL FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSL(ConnectCommandWithSSLTest.java:198)
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithNoSSL FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithNoSSL(ConnectCommandWithSSLTest.java:177)
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithClusterAndJmxSSL FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterAndJmxSSL(ConnectCommandWithSSLTest.java:309)
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithSSLAndThenWithNoSSL FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSLAndThenWithNoSSL(ConnectCommandWithSSLTest.java:320)
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithHttpSSLAndSkipSSLValidation FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithHttpSSLAndSkipSSLValidation(ConnectCommandWithSSLTest.java:286)
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithClusterSSL FAILED
>
[jira] [Created] (GEODE-3815) Entries are incorrectly removed from the index map during parallel gateway queue conflation
Barry Oglesby created GEODE-3815:
Summary: Entries are incorrectly removed from the index map during
parallel gateway queue conflation
Key: GEODE-3815
URL: https://issues.apache.org/jira/browse/GEODE-3815
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barry Oglesby
When an event is sent to a {{Gateway}} queue, it does a put into a map of
indexes tracking realKey to queueKey if conflation is enabled. This put returns
the previous queueKey which sent to a separate {{WAN Queue Conflation Thread}}
thread to be removed from the queue. The {{WAN Queue Conflation Thread}} also
removes the key from the map of indexes. This is not correct behavior. Its
always going to remove a current index.
Here is some logging that shows the behavior. In this case, the
{{ServerConnection}} thread is updating key=0. The previousTailKey=726 (thats
the key in the queue), which the {{WAN Queue Conflation Thread}} removes from
the queue. It also removes index=839 from the index map. This causes the next
update for key=0 into the queue to not find anything in the index map
(previousTailKey=null), so the previous event is not removed from the queue.
{noformat}
ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
putting keyToConflate=0; tailKey=839
ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
previousTailKey=726
WAN Queue Conflation Thread: ConflationHandler.run previousTailKey=726
WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue
about to destroyKey key=726
WAN Queue Conflation Thread: BucketRegionQueue.removeIndex index=839
WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue
done destroyKey key=726
ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
putting keyToConflate=0; tailKey=952
ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
previousTailKey=null
{noformat}
If I remove this code from {{BucketRegionQueue.basicDestroy}} which is called
by the {{WAN Queue Conflation Thread}}, conflation works fine:
{noformat}
if (getPartitionedRegion().isConflationEnabled()) {
removeIndex((Long)event.getKey());
}
{noformat}
The {{WAN Queue Conflation Thread}} handles {{EntryNotFoundException}}, so if
the entry doesn't exist (meaning it already was sent), its ok. Since this
method is also called during normal queue removal, I'm not sure if there are
consequences to removing this code, though. Also, I haven't looked to see if
the serial queue has this same issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-3445:
-
Assignee: Jens Deppe (was: Karen Smoler Miller)
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Jens Deppe
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-3445:
-
Assignee: Karen Smoler Miller (was: Jens Deppe)
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3814) RestAPIsWithSSLDUnitTest tests are incorrect
Jens Deppe created GEODE-3814: - Summary: RestAPIsWithSSLDUnitTest tests are incorrect Key: GEODE-3814 URL: https://issues.apache.org/jira/browse/GEODE-3814 Project: Geode Issue Type: Bug Components: rest (dev) Reporter: Jens Deppe Various tests test different protocols but the actual code that sets up the client ignores the passed protocol and always just ends up using TLSv1.2. This test could also be refactored to use rules. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3814) RestAPIsWithSSLDUnitTest tests are incorrect
[ https://issues.apache.org/jira/browse/GEODE-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-3814: - Assignee: Jens Deppe > RestAPIsWithSSLDUnitTest tests are incorrect > > > Key: GEODE-3814 > URL: https://issues.apache.org/jira/browse/GEODE-3814 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Reporter: Jens Deppe >Assignee: Jens Deppe > > Various tests test different protocols but the actual code that sets up the > client ignores the passed protocol and always just ends up using TLSv1.2. > This test could also be refactored to use rules. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3813) Region registerInterest API usage of type parameters is broken
Kirk Lund created GEODE-3813:
Summary: Region registerInterest API usage of type parameters is
broken
Key: GEODE-3813
URL: https://issues.apache.org/jira/browse/GEODE-3813
Project: Geode
Issue Type: Bug
Components: client/server, regions
Reporter: Kirk Lund
The registerInterest API works for single key registration but is broken for
all other types of registration if the Region is declared with type parameters:
Single key (works):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1);
{noformat}
ALL_KEYS token is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest("ALL_KEYS");
{noformat}
List of keys is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
List listOfKeys = new ArrayList<>();
listOfKeys.add(1);
listOfKeys.add(2);
region.registerInterest(listOfKeys);
{noformat}
When this ticket is fixed and the API is updated, we should consider support
var args:
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1, 2, 3);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GEODE-3813) Region registerInterest API usage of type parameters is broken
[
https://issues.apache.org/jira/browse/GEODE-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-3813:
-
Description:
The registerInterest API works for single key registration but is broken for
all other types of registration if the Region is declared with type parameters:
Single key (works):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1);
{noformat}
ALL_KEYS token is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest("ALL_KEYS");
{noformat}
List of keys is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
List listOfKeys = new ArrayList<>();
listOfKeys.add(1);
listOfKeys.add(2);
region.registerInterest(listOfKeys);
{noformat}
When this ticket is fixed and the API is updated, we should consider adding
support var args:
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1, 2, 3);
{noformat}
was:
The registerInterest API works for single key registration but is broken for
all other types of registration if the Region is declared with type parameters:
Single key (works):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1);
{noformat}
ALL_KEYS token is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest("ALL_KEYS");
{noformat}
List of keys is broken (fails to compile):
{noformat}
Region region = clientRegionFactory.create(regionName);
List listOfKeys = new ArrayList<>();
listOfKeys.add(1);
listOfKeys.add(2);
region.registerInterest(listOfKeys);
{noformat}
When this ticket is fixed and the API is updated, we should consider support
var args:
{noformat}
Region region = clientRegionFactory.create(regionName);
region.registerInterest(1, 2, 3);
{noformat}
> Region registerInterest API usage of type parameters is broken
> --
>
> Key: GEODE-3813
> URL: https://issues.apache.org/jira/browse/GEODE-3813
> Project: Geode
> Issue Type: Bug
> Components: client/server, regions
>Reporter: Kirk Lund
>
> The registerInterest API works for single key registration but is broken for
> all other types of registration if the Region is declared with type
> parameters:
> Single key (works):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1);
> {noformat}
> ALL_KEYS token is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest("ALL_KEYS");
> {noformat}
> List of keys is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> List listOfKeys = new ArrayList<>();
> listOfKeys.add(1);
> listOfKeys.add(2);
> region.registerInterest(listOfKeys);
> {noformat}
> When this ticket is fixed and the API is updated, we should consider adding
> support var args:
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1, 2, 3);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3809) Invalid OQL result to region with entry-idle-time setting
[
https://issues.apache.org/jira/browse/GEODE-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200684#comment-16200684
]
Jason Huynh commented on GEODE-3809:
It looks like the entry is getting it's last access time updated in the local
client cache. That is why the gets continue to work. However the server does
not have its last access time updated and then expires the entry. That is why
the query is no longer returning a value but the client still is able to do a
get.
If you change the client cache to PROXY instead of LOCAL, the query 3 will now
return the correct value because the gets would have updated the servers last
access time for that entry.
If you go back to the LOCAL configuration (and let's ignore queries at this
time), you will still have the scenario where you do gets on the client cache
and the server doesn't get accessed. The server will expire the entry same as
before, but if you register interest from the client, the client would at least
receive the destroy and the local gets would now return null.
Queries, currently, do not update the last access time for the entry. I've
opened GEODE-3811: Queries should update the access time of an entry.
> Invalid OQL result to region with entry-idle-time setting
> -
>
> Key: GEODE-3809
> URL: https://issues.apache.org/jira/browse/GEODE-3809
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Masaki Yamakawa
>
> I am setting the expiration of entry-idle-time to Region. Despite periodic
> access to the region, I discovered an event that data can not be get with OQL
> after the time set by entry-idle-time has elapsed. I am using Geode in the
> production, so I want you to solve this problem as soon as possible.
> The cache.xml of the server is as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
> {code}
> The source code of the client is as follows:
> {code:java}
> private static final Integer KEY = 1;
> public static void main(String[] args) throws Exception {
> Properties props = new Properties();
> props.setProperty("cache-xml-file", "clientcache.xml");
> ClientCacheFactory factory = new ClientCacheFactory(props);
> ClientCache cache = factory.create();
> Region region = cache.getRegion("Data");
> region.put(KEY, "InitialValue");
> Thread.sleep(7000);
> System.out.println("Get Result1=" + region.get(1));
> Pool pool = PoolManager.find("ClientPool");
> Query query = pool.getQueryService().newQuery("select k from
> /Data.keySet k");
> // Normal OQL result
> SelectResults result = SelectResults.class.cast(query.execute());
> System.out.println("Get Result2=" + region.get(1));
> System.out.println("Query Result2=" + result.size() + ", value=" +
> result.iterator().next());
> Thread.sleep(5000);
> // Invalid OQL result!!!
> result = SelectResults.class.cast(query.execute());
> System.out.println("Get Result3=" + region.get(1));
> System.out.println("Query Result3=" + result.size() + ", value=" +
> (result.isEmpty() ? null : result.iterator().next()));
> System.out.println("Get Result4=" + region.get(1));
> cache.close();
> System.exit(0);
> }
> {code}
> {code:xml}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3796) Recording a version during region initialization could throw exception.
[
https://issues.apache.org/jira/browse/GEODE-3796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade resolved GEODE-3796.
--
Resolution: Fixed
Fix Version/s: 1.3.0
> Recording a version during region initialization could throw exception.
> ---
>
> Key: GEODE-3796
> URL: https://issues.apache.org/jira/browse/GEODE-3796
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
> Fix For: 1.3.0
>
>
> The Geode allows cache operation during region initialization; that means a
> cache operation can arrive on a region before the region's version vector is
> registered/added. If a cache operation originated from the same member is
> received before the rvv is registered, the system throws exception (A timing
> issue).
> This happens mostly when a remove/removeAll operation tries to remove entry
> that was originated in the remote node where the region is getting recreated.
> (Reproduced with test trying to record version during initialization):
> org.apache.geode.InternalGemFireError: recordVersion invoked for a local
> version tag that is higher than our local version.
> rvv=RegionVersionVector{rv0 gc0}@177012, tag={v0; rv551903297536; ds=0;
> time=0} region null
> at org.apache.geode.internal.Assert.throwError(Assert.java:94)
> at org.apache.geode.internal.Assert.fail(Assert.java:68)
> at
> org.apache.geode.internal.cache.versions.RegionVersionVector.recordVersion(RegionVersionVector.java:610)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.googlecode.catchexception.internal.ExceptionProcessingInterceptor.intercept(ExceptionProcessingInterceptor.java:72)
> at
> org.apache.geode.internal.cache.versions.RegionVersionVectorJUnitTest$1$$EnhancerByMockitoWithCGLIB$$4a46a9a1.recordVersion()
> at
> org.apache.geode.internal.cache.versions.RegionVersionVectorJUnitTest.testRecordVersionDuringRegionInitializationBeforeRvvIsAdded(RegionVersionVectorJUnitTest.java:551)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3811) Queries should update the access time of an entry
Jason Huynh created GEODE-3811: -- Summary: Queries should update the access time of an entry Key: GEODE-3811 URL: https://issues.apache.org/jira/browse/GEODE-3811 Project: Geode Issue Type: Bug Components: querying Reporter: Jason Huynh Queries currently do not update the last access time for an entry. We should probably update the last access time when a query accesses an entry. Indexes will have some issues if they do not contain a reference to the region entry, such as Range Index. This index will need to either retain information about which entry each tuple was created from or we would have to document cases where indexes would not update the access time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3247) Improve OQL expression execution
[ https://issues.apache.org/jira/browse/GEODE-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-3247. Resolution: Fixed > Improve OQL expression execution > > > Key: GEODE-3247 > URL: https://issues.apache.org/jira/browse/GEODE-3247 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Anthony Baker >Assignee: Karen Smoler Miller > Fix For: 1.3.0 > > > We should validate an OQL expression before attempting to invoke it to > prevent undesirable behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3247) Improve OQL expression execution
[ https://issues.apache.org/jira/browse/GEODE-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200638#comment-16200638 ] ASF subversion and git services commented on GEODE-3247: Commit 9215875f6734f6085e5005e26b1ea0c9edcb2c70 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9215875 ] GEODE-3247 Document query method invocation changes (#909) * GEODE-3247 Document query method invocation changes * GEODE-3247 Revise docs of query method invocation changes * GEODE-3247 Revision per final review comment > Improve OQL expression execution > > > Key: GEODE-3247 > URL: https://issues.apache.org/jira/browse/GEODE-3247 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Anthony Baker >Assignee: Karen Smoler Miller > Fix For: 1.3.0 > > > We should validate an OQL expression before attempting to invoke it to > prevent undesirable behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3247) Improve OQL expression execution
[ https://issues.apache.org/jira/browse/GEODE-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200639#comment-16200639 ] ASF subversion and git services commented on GEODE-3247: Commit 9215875f6734f6085e5005e26b1ea0c9edcb2c70 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9215875 ] GEODE-3247 Document query method invocation changes (#909) * GEODE-3247 Document query method invocation changes * GEODE-3247 Revise docs of query method invocation changes * GEODE-3247 Revision per final review comment > Improve OQL expression execution > > > Key: GEODE-3247 > URL: https://issues.apache.org/jira/browse/GEODE-3247 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Anthony Baker >Assignee: Karen Smoler Miller > Fix For: 1.3.0 > > > We should validate an OQL expression before attempting to invoke it to > prevent undesirable behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3247) Improve OQL expression execution
[ https://issues.apache.org/jira/browse/GEODE-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200636#comment-16200636 ] ASF subversion and git services commented on GEODE-3247: Commit 9215875f6734f6085e5005e26b1ea0c9edcb2c70 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9215875 ] GEODE-3247 Document query method invocation changes (#909) * GEODE-3247 Document query method invocation changes * GEODE-3247 Revise docs of query method invocation changes * GEODE-3247 Revision per final review comment > Improve OQL expression execution > > > Key: GEODE-3247 > URL: https://issues.apache.org/jira/browse/GEODE-3247 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Anthony Baker >Assignee: Karen Smoler Miller > Fix For: 1.3.0 > > > We should validate an OQL expression before attempting to invoke it to > prevent undesirable behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3247) Improve OQL expression execution
[ https://issues.apache.org/jira/browse/GEODE-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200637#comment-16200637 ] ASF subversion and git services commented on GEODE-3247: Commit 9215875f6734f6085e5005e26b1ea0c9edcb2c70 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9215875 ] GEODE-3247 Document query method invocation changes (#909) * GEODE-3247 Document query method invocation changes * GEODE-3247 Revise docs of query method invocation changes * GEODE-3247 Revision per final review comment > Improve OQL expression execution > > > Key: GEODE-3247 > URL: https://issues.apache.org/jira/browse/GEODE-3247 > Project: Geode > Issue Type: Bug > Components: docs, querying >Reporter: Anthony Baker >Assignee: Karen Smoler Miller > Fix For: 1.3.0 > > > We should validate an OQL expression before attempting to invoke it to > prevent undesirable behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3810) CI failure: UpdateVersionDUnitTest.testUpdateVersionAfterCreateWithSerialSenderOnDR failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200627#comment-16200627
]
Barry Oglesby commented on GEODE-3810:
--
This failure is happening on the local site, not the remote site. It is
comparing the entry's {{VersionStamp}} time to the test-generated timestamp,
and its failing.
With some added logging in the test, I see:
The {{VersionStamp}} from the entry {{VersionStamp stamp =
regionEntry.getVersionStamp())}} reports:
{noformat}
[vm0] [warn 2017/10/10 13:52:49.590 PDT
tid=19] XXX UpdateVersionDUnitTest.call invoked
stamp1=NonLocalRegionEntry(key-1; value=VMCachedDeserializable@703608312;
version={v2; rv2; ds=1; time=1507676208606}
{noformat}
The generated {{VersionTag}} created with {{System.currentTimeMillis}} is an
earlier time:
{noformat}
[vm0] [warn 2017/10/10 13:52:49.591 PDT
tid=19] XXX UpdateVersionDUnitTest.call invoked tag={v1; rv0;
mbr=192.168.2.6(70798):32770; ds=1; time=1507676208605; remote}
{noformat}
And the {{VersionStamp}} from the entry is the original one:
{noformat}
[vm0] [warn 2017/10/10 13:52:49.591 PDT
tid=19] XXX UpdateVersionDUnitTest.call invoked
stamp2=NonLocalRegionEntry(key-1; value=VMCachedDeserializable@703608312;
version={v2; rv2; ds=1; time=1507676208606}
{noformat}
There are three put operations in this test - two using public API and one
using internal API. All of them were generated at the same time, but the time
is incremented by one in the second one in
{{AbstractRegionEntry.generateVersionTag}}.
I added some logging in {{AbstractRegionEntry.generateVersionTag}}:
{noformat}
long time = region.cacheTimeMillis();
==>System.out.println("cts=" + time);
int dsid = region.getDistributionManager().getDistributedSystemId();
// a locally generated change should always have a later timestamp than
// one received from a wan gateway, so fake a timestamp if necessary
==>System.out.println("dsid=" + dsid + ";tagDsid=" +
tag.getDistributedSystemId());
if (time <= stamp.getVersionTimeStamp() && dsid !=
tag.getDistributedSystemId()) {
time = stamp.getVersionTimeStamp() + 1;
==> System.out.println("cts2=" + time);
}
{noformat}
It shows:
{{AbstractRegionEntry.generateVersionTag}} generates timestamp=1507676208605
for the first put:
{noformat}
[vm0] About to put 1
[vm0] cts=1507676208605
[vm0] dsid=1;tagDsid=0
[vm0] Done put 1
{noformat}
{{AbstractRegionEntry.generateVersionTag}} generates the same timestamp for the
second put, but increments it by 1:
{noformat}
[vm0] About to put 2
[vm0] cts=1507676208605
[vm0] dsid=1;tagDsid=0
[vm0] cts2=1507676208606
[vm0] Done put 2
{noformat}
The timestamp generated by the test using {{System.currentTimeMillis()}} in the
3rd put is the same, which causes the {{AssertionError}}:
{noformat}
[vm0] tagTs=1507676208605; dsid=1; tagDsid=1
{noformat}
{noformat}
[vm0] [info 2017/10/10 15:56:48.612 PDT
tid=0x13] Got result: EXCEPTION_OCCURRED
[vm0] java.lang.AssertionError: Time stamp did NOT get updated by
UPDATE_VERSION operation on LocalRegion expected:<1507676208605> but
was:<1507676208606>
[vm0] at org.junit.Assert.fail(Assert.java:88)
{noformat}
I'm not sure I understand the reason {{AbstractRegionEntry.generateVersionTag}}
increments the timestamp:
{noformat}
if (time <= stamp.getVersionTimeStamp() && dsid !=
tag.getDistributedSystemId()) {
time = stamp.getVersionTimeStamp() + 1;
System.out.println("cts2=" + time);
}
{noformat}
The {{tag}} being used in this call has just been created in this method, so
its {{distributedSystemId}} has not been set:
{noformat}
VersionTag tag = VersionTag.create(member);
{noformat}
Its always going to be 0, so the second clause will be true. Is that correct
behavior?
All four test cases in this test can fail for the same reason.
Also, I see the {{UpdateVersionJUnitTest}} increments the timestamp by one when
it generates the timestamp for the third put:
{noformat}
long time = System.currentTimeMillis() + 1;
{noformat}
> CI failure:
> UpdateVersionDUnitTest.testUpdateVersionAfterCreateWithSerialSenderOnDR
> failed with AssertionError
> --
>
> Key: GEODE-3810
> URL: https://issues.apache.org/jira/browse/GEODE-3810
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Barry Oglesby
>
> {noformat}
> org.apache.geode.internal.cache.UpdateVersionDUnitTest >
> testUpdateVersionAfterCreateWithSerialSenderOnDR FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.UpdateVersionDUnitTest$4.call in VM 0 running
> on Host e7658d4217a2 with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at
[jira] [Assigned] (GEODE-3774) Remove double-checked Locking in New Client Protocol code
[
https://issues.apache.org/jira/browse/GEODE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-3774:
Assignee: Michael Dodge
> Remove double-checked Locking in New Client Protocol code
> -
>
> Key: GEODE-3774
> URL: https://issues.apache.org/jira/browse/GEODE-3774
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Galen O'Sullivan
>Assignee: Michael Dodge
>
> {{ServerConnectionFactory}} uses double-checked locking for loading the
> services it depends on. This idiom is fundamentally broken.
> Even marking the field that's locked this way {{volatile}} may not resolve
> the issue, as the object itself could be read as uninitialized even if the
> field (reference) isn't. I don't really know the JMM well enough to be sure
> that it's broken, but that's a good sign that we shouldn't do it unless we
> really need to for performance reasons (and even then...)
> This may be best to resolve after GEODE-3751 and GEODE-3739 due to the
> changes to loading those refactors will bring.
> While we're at it, we should assert that there is only one client protocol
> service, because we can't handle two and which one we choose is undefined.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3774) Remove double-checked Locking in New Client Protocol code
[
https://issues.apache.org/jira/browse/GEODE-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-3774:
Assignee: Udo Kohlmeyer (was: Michael Dodge)
> Remove double-checked Locking in New Client Protocol code
> -
>
> Key: GEODE-3774
> URL: https://issues.apache.org/jira/browse/GEODE-3774
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Galen O'Sullivan
>Assignee: Udo Kohlmeyer
>
> {{ServerConnectionFactory}} uses double-checked locking for loading the
> services it depends on. This idiom is fundamentally broken.
> Even marking the field that's locked this way {{volatile}} may not resolve
> the issue, as the object itself could be read as uninitialized even if the
> field (reference) isn't. I don't really know the JMM well enough to be sure
> that it's broken, but that's a good sign that we shouldn't do it unless we
> really need to for performance reasons (and even then...)
> This may be best to resolve after GEODE-3751 and GEODE-3739 due to the
> changes to loading those refactors will bring.
> While we're at it, we should assert that there is only one client protocol
> service, because we can't handle two and which one we choose is undefined.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3810) CI failure: UpdateVersionDUnitTest.testUpdateVersionAfterCreateWithSerialSenderOnDR failed with AssertionError
Barry Oglesby created GEODE-3810:
Summary: CI failure:
UpdateVersionDUnitTest.testUpdateVersionAfterCreateWithSerialSenderOnDR failed
with AssertionError
Key: GEODE-3810
URL: https://issues.apache.org/jira/browse/GEODE-3810
Project: Geode
Issue Type: Bug
Components: core
Reporter: Barry Oglesby
{noformat}
org.apache.geode.internal.cache.UpdateVersionDUnitTest >
testUpdateVersionAfterCreateWithSerialSenderOnDR FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.UpdateVersionDUnitTest$4.call in VM 0 running
on Host e7658d4217a2 with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
at org.apache.geode.test.dunit.VM.invoke(VM.java:331)
at
org.apache.geode.internal.cache.UpdateVersionDUnitTest.testUpdateVersionAfterCreateWithSerialSenderOnDR(UpdateVersionDUnitTest.java:272)
Caused by:
java.lang.AssertionError: Time stamp did NOT get updated by
UPDATE_VERSION operation on LocalRegion expected:<1507601466346> but
was:<1507601466347>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands
[ https://issues.apache.org/jira/browse/GEODE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200599#comment-16200599 ] ASF subversion and git services commented on GEODE-3539: Commit b2c7605e756bccdd24a94384f851352ff6bb7b90 in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b2c7605 ] GEODE-3539: consolidate IndexType for better option verification (#910) * consolidate IndexType * simplify IndexType class and fix analyzeSerializable test * add unit test to make sure old behavior is preserved > Add more test coverage for p2p commands > --- > > Key: GEODE-3539 > URL: https://issues.apache.org/jira/browse/GEODE-3539 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jinmei Liao > > Add more command tests that would eventually get rid of the legacy tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3798) Move logic for information in restore script to own class
[ https://issues.apache.org/jira/browse/GEODE-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich reassigned GEODE-3798: - Assignee: Nick Reich > Move logic for information in restore script to own class > - > > Key: GEODE-3798 > URL: https://issues.apache.org/jira/browse/GEODE-3798 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich > > Currently, the BackupManager contains all the logic for what files need to be > included in the backup script. This logic should be moved out into its own > class. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3797) Remove correlation ID from new protocol
[ https://issues.apache.org/jira/browse/GEODE-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-3797: Assignee: Udo Kohlmeyer > Remove correlation ID from new protocol > --- > > Key: GEODE-3797 > URL: https://issues.apache.org/jira/browse/GEODE-3797 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Brian Baynes >Assignee: Udo Kohlmeyer > > Since the new protocol is not yet using the correlation ID on messages, > remove it for now. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3731) CI failure: DistributionManagerDUnitTest.testAckSevereAlertThreshold failed with assertion
[ https://issues.apache.org/jira/browse/GEODE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-3731. -- Resolution: Fixed > CI failure: DistributionManagerDUnitTest.testAckSevereAlertThreshold failed > with assertion > -- > > Key: GEODE-3731 > URL: https://issues.apache.org/jira/browse/GEODE-3731 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Hitesh Khamesra >Assignee: Udo Kohlmeyer > > org.apache.geode.distributed.internal.DistributionManagerDUnitTest > > testAckSevereAlertThreshold FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.distributed.internal.DistributionManagerDUnitTest$2.run in > VM 1 running on Host 989f9beaa656 with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:393) > at org.apache.geode.test.dunit.VM.invoke(VM.java:363) > at org.apache.geode.test.dunit.VM.invoke(VM.java:308) > at > org.apache.geode.distributed.internal.DistributionManagerDUnitTest.testAckSevereAlertThreshold(DistributionManagerDUnitTest.java:277) > Caused by: > java.lang.AssertionError -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3802) Ensure no public APIs and all under internal
[ https://issues.apache.org/jira/browse/GEODE-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200555#comment-16200555 ] ASF subversion and git services commented on GEODE-3802: Commit 9333b13cc11af2f6570fe8057c64e7b7716c03ad in geode's branch refs/heads/develop from kohlmu-pivotal [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9333b13 ] GEODE-3802: Amending package renaming issues > Ensure no public APIs and all under internal > > > Key: GEODE-3802 > URL: https://issues.apache.org/jira/browse/GEODE-3802 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Brian Baynes >Assignee: Udo Kohlmeyer > Fix For: 1.3.0 > > > Ensure new protocol has no public APIs and is all under *internal* package. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3131) CI Failure: org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.testRefCountForNormalAndGIIPut
[ https://issues.apache.org/jira/browse/GEODE-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-3131. Fix Version/s: 1.3.0 > CI Failure: > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.testRefCountForNormalAndGIIPut > -- > > Key: GEODE-3131 > URL: https://issues.apache.org/jira/browse/GEODE-3131 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.1.0 >Reporter: Jason Huynh > Fix For: 1.3.0 > > > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest > > testRefCountForNormalAndGIIPut FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$95/1198712296.run > in VM 1 running on Host 893875957fbb with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:344) > at org.apache.geode.test.dunit.VM.invoke(VM.java:314) > at org.apache.geode.test.dunit.VM.invoke(VM.java:259) > at > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.testRefCountForNormalAndGIIPut(HARQueueNewImplDUnitTest.java:383) > Caused by: > java.lang.AssertionError: expected:<3> but was:<2> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.verifyQueueData(HARQueueNewImplDUnitTest.java:1061) > at > org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.lambda$testRefCountForNormalAndGIIPut$bb17a952$11(HARQueueNewImplDUnitTest.java:383) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (GEODE-3445) Add Gfsh Connect option --skip-ssl-validation
[
https://issues.apache.org/jira/browse/GEODE-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reopened GEODE-3445:
Assignee: Karen Smoler Miller (was: Jared Stewart)
Reopening ticket to complete documentation of the new gfsh connect option.
> Add Gfsh Connect option --skip-ssl-validation
> -
>
> Key: GEODE-3445
> URL: https://issues.apache.org/jira/browse/GEODE-3445
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh
>Reporter: Jared Stewart
>Assignee: Karen Smoler Miller
> Fix For: 1.3.0
>
>
> We have users who would like to connect to a locator from gfsh over HTTPS
> without verifying the hostname of the locator. (This is a common pattern in
> testing environments or where self-signed certificates are used.) We already
> have some code used for tests to enable this behavior:
> {noformat}
>// This is for testing purpose only. If we remove this piece of code we
> will
> // get a java.security.cert.CertificateException
> // as matching hostname can not be obtained in all test environment.
> HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
> @Override
> public boolean verify(String string, SSLSession ssls) {
> return true;
> }
> });
> {noformat}
> We just need to conditionally call this code inside Gfsh Connect if the
> --skip-ssl-validation option is specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3809) Invalid OQL result to region with entry-idle-time setting
Masaki Yamakawa created GEODE-3809:
--
Summary: Invalid OQL result to region with entry-idle-time setting
Key: GEODE-3809
URL: https://issues.apache.org/jira/browse/GEODE-3809
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Masaki Yamakawa
I am setting the expiration of entry-idle-time to Region. Despite periodic
access to the region, I discovered an event that data can not be get with OQL
after the time set by entry-idle-time has elapsed. I am using Geode in the
production, so I want you to solve this problem as soon as possible.
The cache.xml of the server is as follows:
{code:xml}
{code}
The source code of the client is as follows:
{code:java}
private static final Integer KEY = 1;
public static void main(String[] args) throws Exception {
Properties props = new Properties();
props.setProperty("cache-xml-file", "clientcache.xml");
ClientCacheFactory factory = new ClientCacheFactory(props);
ClientCache cache = factory.create();
Region region = cache.getRegion("Data");
region.put(KEY, "InitialValue");
Thread.sleep(7000);
System.out.println("Get Result1=" + region.get(1));
Pool pool = PoolManager.find("ClientPool");
Query query = pool.getQueryService().newQuery("select k from
/Data.keySet k");
// Normal OQL result
SelectResults result = SelectResults.class.cast(query.execute());
System.out.println("Get Result2=" + region.get(1));
System.out.println("Query Result2=" + result.size() + ", value=" +
result.iterator().next());
Thread.sleep(5000);
// Invalid OQL result!!!
result = SelectResults.class.cast(query.execute());
System.out.println("Get Result3=" + region.get(1));
System.out.println("Query Result3=" + result.size() + ", value=" +
(result.isEmpty() ? null : result.iterator().next()));
System.out.println("Get Result4=" + region.get(1));
cache.close();
System.exit(0);
}
{code}
{code:xml}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3424) User can pass authorization instance to CacheFactory
[
https://issues.apache.org/jira/browse/GEODE-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200185#comment-16200185
]
ASF subversion and git services commented on GEODE-3424:
Commit 2aa801a3e4dbb9091b221ca7131df24c94e44f33 in geode-native's branch
refs/heads/develop from [~mhansonp]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2aa801a ]
GEODE-3424: Pass instance of AuthInitailize into CacheFactory.
- Remove old properties based library and factory loading.
- Removes old test.
> User can pass authorization instance to CacheFactory
>
>
> Key: GEODE-3424
> URL: https://issues.apache.org/jira/browse/GEODE-3424
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Addison
>
> Today, the loading of the native client authorization module is difficult,
> especially with IIS. To load the auth assembly it must be located in the IIS
> installation directory and this can vary from machine to machine.
> A better approach is to allow users to pass in an instance of the auth class
> into the CacheFactory. This will work well with app domains as well.
> Something like this
> {code}
> var auth = new MyAuth();
> CacheFactory.setAuthHandler(auth);
> var cache = cacheFactory.create();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3807) Update libxml2 to 2.9.6
[ https://issues.apache.org/jira/browse/GEODE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200183#comment-16200183 ] ASF subversion and git services commented on GEODE-3807: Commit c4cd70408abacce0a77ea68f008bdb552902da27 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=c4cd704 ] GEODE-3807: Updated to libxml2 2.9.6. > Update libxml2 to 2.9.6 > --- > > Key: GEODE-3807 > URL: https://issues.apache.org/jira/browse/GEODE-3807 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
