[jira] [Commented] (GEODE-6751) CI failure: AcceptanceTestOpenJDK8 ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure
[ https://issues.apache.org/jira/browse/GEODE-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408547#comment-17408547 ] Geode Integration commented on GEODE-6751: -- Seen in [upgrade-test-openjdk8 #166|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/166] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0460/test-results/upgradeTest/1630554797/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0460/test-artifacts/1630554797/upgradetestfiles-openjdk8-1.15.0-build.0460.tgz]. > CI failure: AcceptanceTestOpenJDK8 > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure > - > > Key: GEODE-6751 > URL: https://issues.apache.org/jira/browse/GEODE-6751 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.15.0 >Reporter: Scott Jewell >Priority: Major > > Assertion failure in > ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator > Appears to be a new bug > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest > > useCurrentGfshToConnectToOlderLocator FAILED > java.lang.AssertionError: > Expecting: > <" > (1) Executing - connect > Connecting to Locator at [host=localhost, port=10334] .. > Exception caused JMX Manager startup to fail because: 'HTTP service > failed to start' > "> > to contain: > <"Cannot use a"> > at > org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandAcceptanceTest.java:50) > 60 tests completed, 1 failed > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-results/acceptanceTest/1557290414/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-artifacts/1557290414/acceptancetestfiles-OpenJDK8-1.10.0-SNAPSHOT.0258.tgz*] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9518) Implement ZUNIONSTORE Command
[ https://issues.apache.org/jira/browse/GEODE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408463#comment-17408463 ] ASF subversion and git services commented on GEODE-9518: Commit ae8d6745a7a1c4ce3a1c3f80c80ca906f53d5e82 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ae8d674 ] GEODE-9518: Implement Radish ZUNIONSTORE command (#6794) - Add ability to lock multiple keys in a consistent order - Add validation option to ConcurrentLoopingThreads - Add CROSSSLOTS error message > Implement ZUNIONSTORE Command > - > > Key: GEODE-9518 > URL: https://issues.apache.org/jira/browse/GEODE-9518 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Implement the [ZUNIONSTORE|https://redis.io/commands/zunionstore] Command, > with all options, and associated tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9575) redis publish sends an extra message to each server
Darrel Schneider created GEODE-9575:
---
Summary: redis publish sends an extra message to each server
Key: GEODE-9575
URL: https://issues.apache.org/jira/browse/GEODE-9575
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Darrel Schneider
The redis publish command uses a geode function to distribute the publish to
each server that may have subscriptions. When it does this it calls
PartitionRegionHelper.getPartitionRegionInfo. It turns out the implementation
of this method sends a message to each data store: FetchPartitionDetailsMessage.
Since all redis publish wanted to do was execute the function on each server
that has the redis data region, it could have instead done it like so in
RegionProvider.getRegionMembers:
{code:java}
Set otherMembers =
partitionedRegion.getRegionAdvisor().adviseDataStore();
Set result = new HashSet<>(otherMembers.size()+1);
result.addAll(otherMembers);
result.add(partitionedRegion.getDistributionManager().getDistributionManagerId());
return result;
{code}
When I did this I started seeing one of the tests fail. It looked like it might
had to do with something left around from one test method interfering with
another. It is possible that the older slow code works in this test because the
extra messaging slows publish down. It was a dunit test that did some ha
(starting and stopping servers). I verified that this code does produce the
same set of members as the old code but I did not figure out what was wrong
with the test that started failing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache Geode project
[
https://issues.apache.org/jira/browse/GEODE-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408450#comment-17408450
]
Dave Barnes commented on GEODE-6402:
[~alberto.bustamante.reyes] I approved your pull request and merged the change
in the geode-site master branch.
There is a bit more housekeeping to do before closing this ticket.
- To pass Geode's down-rev RAT test, the link in the license body had to be
changed to 'http:' instead of 'https:'. I did that.
- To position the file at the top level of the published site, the file needed
to be added on the asf-site branch, rather than the master branch. I made that
change.
- After the next website update (1.14, happening in early Sep 2021), there's
another task you described in your PR:
Once it is added and publicly available, it has to be added to a xml file in
the `projects.apache.org` page, check "Submitting your file" section here :
https://projects.apache.org/create.html. I'll leave that for you to complete.
Thanks for your contribution!
> Create a DOAP file for the Apache Geode project
> ---
>
> Key: GEODE-6402
> URL: https://issues.apache.org/jira/browse/GEODE-6402
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> An Apache project can (and should) have a DOAP ("Description Of A Project")
> file that describes the project and provides some details. The DOAP allows
> the project to be found via language and category searches, provides release
> and repo information, etc.
> Here's a link to the Apache page that gets you started:
> [https://projects.apache.org/create.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9519) Implement ZSCAN Command
[ https://issues.apache.org/jira/browse/GEODE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9519: -- Labels: pull-request-available (was: ) > Implement ZSCAN Command > --- > > Key: GEODE-9519 > URL: https://issues.apache.org/jira/browse/GEODE-9519 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Implement the [ZSCAN|https://redis.io/commands/zscan] command with associated > options, and tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9574) Changes to exception handling may be causing changes to connection state.
[
https://issues.apache.org/jira/browse/GEODE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-9574:
Assignee: Jacob Barrett
> Changes to exception handling may be causing changes to connection state.
> -
>
> Key: GEODE-9574
> URL: https://issues.apache.org/jira/browse/GEODE-9574
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> {{OpExectorImpl}} has very specific exception cause checks that may have been
> affected by adding a cause to certain exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9574) Changes to exception handling may be causing changes to connection state.
[
https://issues.apache.org/jira/browse/GEODE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9574:
--
Labels: pull-request-available (was: )
> Changes to exception handling may be causing changes to connection state.
> -
>
> Key: GEODE-9574
> URL: https://issues.apache.org/jira/browse/GEODE-9574
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> {{OpExectorImpl}} has very specific exception cause checks that may have been
> affected by adding a cause to certain exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9574) Changes to exception handling may be causing changes to connection state.
Jacob Barrett created GEODE-9574:
Summary: Changes to exception handling may be causing changes to
connection state.
Key: GEODE-9574
URL: https://issues.apache.org/jira/browse/GEODE-9574
Project: Geode
Issue Type: Bug
Reporter: Jacob Barrett
{{OpExectorImpl}} has very specific exception cause checks that may have been
affected by adding a cause to certain exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett closed GEODE-9551.
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-9551.
-
Resolution: Fixed
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9551:
-
Fix Version/s: 1.15.0
1.14.0
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9573) DirectReplySender can fail with UnsupportedOperationException upon connection related exceptions
[
https://issues.apache.org/jira/browse/GEODE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9573:
--
Labels: pull-request-available (was: )
> DirectReplySender can fail with UnsupportedOperationException upon connection
> related exceptions
>
>
> Key: GEODE-9573
> URL: https://issues.apache.org/jira/browse/GEODE-9573
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> java.lang.UnsupportedOperationException
> at java.base/java.util.Collections$1.remove(Collections.java:4714)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:330)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:69)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:115)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:458)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2077)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:1841)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.dispatchMessage(GMSMembership.java:847)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.handleOrDeferMessage(GMSMembership.java:804)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.processMessage(GMSMembership.java:1102)
> at
> org.apache.geode.distributed.internal.DistributionImpl$MyDCReceiver.messageReceived(DistributionImpl.java:838)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:624)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:682)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3264)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3015)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2806)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache Geode project
[
https://issues.apache.org/jira/browse/GEODE-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408388#comment-17408388
]
ASF GitHub Bot commented on GEODE-6402:
---
davebarnes97 merged pull request #10:
URL: https://github.com/apache/geode-site/pull/10
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Create a DOAP file for the Apache Geode project
> ---
>
> Key: GEODE-6402
> URL: https://issues.apache.org/jira/browse/GEODE-6402
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> An Apache project can (and should) have a DOAP ("Description Of A Project")
> file that describes the project and provides some details. The DOAP allows
> the project to be found via language and category searches, provides release
> and repo information, etc.
> Here's a link to the Apache page that gets you started:
> [https://projects.apache.org/create.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408386#comment-17408386
]
ASF subversion and git services commented on GEODE-6042:
Commit 2c7687871a3f6582a30017981559d0bfd6f1707c in geode-site's branch
refs/heads/master from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=2c76878 ]
Merge pull request #10 from Nordix/feature/GEODE-6042
GEODE-6402: Create DOAP file for Geode
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache Geode project
[
https://issues.apache.org/jira/browse/GEODE-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408385#comment-17408385
]
ASF subversion and git services commented on GEODE-6402:
Commit 8559251e08fb349113f638ada0d04baf5e95e3f4 in geode-site's branch
refs/heads/master from Alberto Bustamante
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=8559251 ]
GEODE-6402: Create DOAP file for Geode
> Create a DOAP file for the Apache Geode project
> ---
>
> Key: GEODE-6402
> URL: https://issues.apache.org/jira/browse/GEODE-6402
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> An Apache project can (and should) have a DOAP ("Description Of A Project")
> file that describes the project and provides some details. The DOAP allows
> the project to be found via language and category searches, provides release
> and repo information, etc.
> Here's a link to the Apache page that gets you started:
> [https://projects.apache.org/create.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6402) Create a DOAP file for the Apache Geode project
[
https://issues.apache.org/jira/browse/GEODE-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408387#comment-17408387
]
ASF subversion and git services commented on GEODE-6402:
Commit 2c7687871a3f6582a30017981559d0bfd6f1707c in geode-site's branch
refs/heads/master from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=2c76878 ]
Merge pull request #10 from Nordix/feature/GEODE-6042
GEODE-6402: Create DOAP file for Geode
> Create a DOAP file for the Apache Geode project
> ---
>
> Key: GEODE-6402
> URL: https://issues.apache.org/jira/browse/GEODE-6402
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> An Apache project can (and should) have a DOAP ("Description Of A Project")
> file that describes the project and provides some details. The DOAP allows
> the project to be found via language and category searches, provides release
> and repo information, etc.
> Here's a link to the Apache page that gets you started:
> [https://projects.apache.org/create.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9573) DirectReplySender can fail with UnsupportedOperationException upon connection related exceptions
[
https://issues.apache.org/jira/browse/GEODE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-9573:
Assignee: Jacob Barrett
> DirectReplySender can fail with UnsupportedOperationException upon connection
> related exceptions
>
>
> Key: GEODE-9573
> URL: https://issues.apache.org/jira/browse/GEODE-9573
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>
> {noformat}
> java.lang.UnsupportedOperationException
> at java.base/java.util.Collections$1.remove(Collections.java:4714)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:330)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:69)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:115)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:458)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2077)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:1841)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.dispatchMessage(GMSMembership.java:847)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.handleOrDeferMessage(GMSMembership.java:804)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.processMessage(GMSMembership.java:1102)
> at
> org.apache.geode.distributed.internal.DistributionImpl$MyDCReceiver.messageReceived(DistributionImpl.java:838)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:624)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:682)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3264)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3015)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2806)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9573) DirectReplySender can fail with UnsupportedOperationException upon connection related exceptions
[
https://issues.apache.org/jira/browse/GEODE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408384#comment-17408384
]
Jacob Barrett commented on GEODE-9573:
--
Changes to use {{Collections.singletonList()}} caused failure in mutation in
the {{MsgStreamer}}.
> DirectReplySender can fail with UnsupportedOperationException upon connection
> related exceptions
>
>
> Key: GEODE-9573
> URL: https://issues.apache.org/jira/browse/GEODE-9573
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
>
> {noformat}
> java.lang.UnsupportedOperationException
> at java.base/java.util.Collections$1.remove(Collections.java:4714)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:330)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:69)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:115)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:458)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2077)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:1841)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.dispatchMessage(GMSMembership.java:847)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.handleOrDeferMessage(GMSMembership.java:804)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.processMessage(GMSMembership.java:1102)
> at
> org.apache.geode.distributed.internal.DistributionImpl$MyDCReceiver.messageReceived(DistributionImpl.java:838)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:624)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:682)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3264)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3015)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2806)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9573) DirectReplySender can fail with UnsupportedOperationException upon connection related exceptions
Jacob Barrett created GEODE-9573:
Summary: DirectReplySender can fail with
UnsupportedOperationException upon connection related exceptions
Key: GEODE-9573
URL: https://issues.apache.org/jira/browse/GEODE-9573
Project: Geode
Issue Type: Bug
Components: messaging
Affects Versions: 1.15.0
Reporter: Jacob Barrett
{noformat}
java.lang.UnsupportedOperationException
at java.base/java.util.Collections$1.remove(Collections.java:4714)
at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:330)
at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
at
org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:69)
at
org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:115)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:458)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at
org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2077)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:1841)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.dispatchMessage(GMSMembership.java:847)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.handleOrDeferMessage(GMSMembership.java:804)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.processMessage(GMSMembership.java:1102)
at
org.apache.geode.distributed.internal.DistributionImpl$MyDCReceiver.messageReceived(DistributionImpl.java:838)
at
org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:624)
at
org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:682)
at
org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3264)
at
org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3015)
at
org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2806)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9572) Ensure valid parameter combinations in test framework "Cluster" object
Blake Bender created GEODE-9572: --- Summary: Ensure valid parameter combinations in test framework "Cluster" object Key: GEODE-9572 URL: https://issues.apache.org/jira/browse/GEODE-9572 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender The current C++ test framework works well as far as it goes, but the Cluster object, which is just a wrapper around a call to gfsh, doesn't examine its parameters pretty much at all. This means it's easy to build and run code that attempts to launch gfsh with invalid or missing parameters. If we built this knowledge into the Cluster class, we could make this fail at build time, rather than run time, saving developers' time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9519) Implement ZSCAN Command
[ https://issues.apache.org/jira/browse/GEODE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9519: -- Assignee: Donal Evans > Implement ZSCAN Command > --- > > Key: GEODE-9519 > URL: https://issues.apache.org/jira/browse/GEODE-9519 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > > Implement the [ZSCAN|https://redis.io/commands/zscan] command with associated > options, and tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9571) Radish REMRANGE* DUnit tests may fail in stress-test
Donal Evans created GEODE-9571:
--
Summary: Radish REMRANGE* DUnit tests may fail in stress-test
Key: GEODE-9571
URL: https://issues.apache.org/jira/browse/GEODE-9571
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
Failures were seen in pre-checkin stress-new-test for
ZRemRangeByScoreDUnitTest, ZRemRangeByRankDUnitTest and
ZRemRangeByLexDUnitTest, all of which use similar test methods. The failures
were seen in the *RemovesMembersFromSortedSetAfterPrimaryShutsDown() test and
the *CanRemoveMembersFromSortedSetWhenPrimaryIsCrashed() test in a few
different runs.
The failures in *CanRemoveMembersFromSortedSetWhenPrimaryIsCrashed() were seen
when the tests for both ZRemRangeByScoreDUnitTest and ZRemRangeByRankDUnitTest
were being run at the same time due to both classes being changed. It's
possibly relevant that the difference in the second assertion
(expected:<[999]L> but was:<[498]L>) is exactly the incorrect number of members
removed in the first assertion (expected:<[499]L> but was:<[501]L>):
{noformat}
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest >
zRemRangeByScoreCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed FAILED
java.util.concurrent.ExecutionException: org.junit.ComparisonFailure:
expected:<[499]L> but was:<[501]L>
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.zRemRangeByScoreCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed(ZRemRangeByScoreDUnitTest.java:159)
Caused by:
org.junit.ComparisonFailure: expected:<[499]L> but was:<[501]L>
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.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.removeAllButFirstEntry(ZRemRangeByScoreDUnitTest.java:213)
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest >
zRemRangeByRankCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed FAILED
java.util.concurrent.ExecutionException: org.junit.ComparisonFailure:
expected:<[999]L> but was:<[498]L>
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest.zRemRangeByRankCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed(ZRemRangeByRankDUnitTest.java:144)
Caused by:
org.junit.ComparisonFailure: expected:<[999]L> but was:<[498]L>
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.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest.removeAllButFirstEntry(ZRemRangeByRankDUnitTest.java:206)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6803/test-results/repeatTest/1630442126/]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6803/test-artifacts/1630442126/stressnewtestfiles-geode-pr-6803.tgz]
The same failure was also seen in this second run, along with a failure in
ZRemRangeByScoreDUnitTest >
zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown due to the
remove command not finding any members to remove:
{noformat}
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest >
zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown FAILED
org.junit.ComparisonFailure: expected:<[50]0L> but was:<[]0L>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.zRemRangeByScoreWithRetries(ZRemRangeByScoreDUnitTest.java:252)
at
[jira] [Updated] (GEODE-9570) Make sure registered interests will re-authenticate when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9570: --- Labels: GeodeOperationAPI (was: ) > Make sure registered interests will re-authenticate when auth expired > - > > Key: GEODE-9570 > URL: https://issues.apache.org/jira/browse/GEODE-9570 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9570) Make sure registered interests will re-authenticate when auth expired
Jinmei Liao created GEODE-9570: -- Summary: Make sure registered interests will re-authenticate when auth expired Key: GEODE-9570 URL: https://issues.apache.org/jira/browse/GEODE-9570 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9457) Investigate the behavior of CQ when authentication expires.
[ https://issues.apache.org/jira/browse/GEODE-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9457: --- Summary: Investigate the behavior of CQ when authentication expires. (was: Investigate the behavior of CQ and registered interests when authentication expires.) > Investigate the behavior of CQ when authentication expires. > --- > > Key: GEODE-9457 > URL: https://issues.apache.org/jira/browse/GEODE-9457 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > To ensure CQ message delivery when a user expires, we need to: > # authorize the message when dispatching the message. > # catch the AuthExpiredException and send REAUTHENTICATE message to the > client > # The client gets that message and re-authenticate > # the message dispatcher will use the new subject to authorize the message > again and try deliver > # if client didn't re-authenticate back in a timely manner, the proxy should > close the connection > # make sure this also works in multi-user mode > To have the message dispatcher to use the newly updated user to authorize the > message, we need to be able to associate the new userId with the old userId. > This would require > 7: have the AuthenticateUserOp send the old userId if exists > make sure to include tests in multi-server cases -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9457) Investigate the behavior of CQ and registered interests when authentication expires.
[ https://issues.apache.org/jira/browse/GEODE-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9457: --- Description: To ensure CQ message delivery when a user expires, we need to: # authorize the message when dispatching the message. # catch the AuthExpiredException and send REAUTHENTICATE message to the client # The client gets that message and re-authenticate # the message dispatcher will use the new subject to authorize the message again and try deliver # if client didn't re-authenticate back in a timely manner, the proxy should close the connection # make sure this also works in multi-user mode To have the message dispatcher to use the newly updated user to authorize the message, we need to be able to associate the new userId with the old userId. This would require 7: have the AuthenticateUserOp send the old userId if exists make sure to include tests in multi-server cases was: We need to find out what's the current behavior of cq and registered interests when authentication expires and see if the behavior matches the expectation make sure to include tests in multi-server cases > Investigate the behavior of CQ and registered interests when authentication > expires. > > > Key: GEODE-9457 > URL: https://issues.apache.org/jira/browse/GEODE-9457 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > To ensure CQ message delivery when a user expires, we need to: > # authorize the message when dispatching the message. > # catch the AuthExpiredException and send REAUTHENTICATE message to the > client > # The client gets that message and re-authenticate > # the message dispatcher will use the new subject to authorize the message > again and try deliver > # if client didn't re-authenticate back in a timely manner, the proxy should > close the connection > # make sure this also works in multi-user mode > To have the message dispatcher to use the newly updated user to authorize the > message, we need to be able to associate the new userId with the old userId. > This would require > 7: have the AuthenticateUserOp send the old userId if exists > make sure to include tests in multi-server cases -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9497) RedisHash and RedisSortedSet both use a hashMap that uses more memory than it needs to
[ https://issues.apache.org/jira/browse/GEODE-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408305#comment-17408305 ] ASF subversion and git services commented on GEODE-9497: Commit 93c1864219d29b2725bea4725cc00e4516507b18 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=93c1864 ] GEODE-9497: create new hash map class with fewer fields (#6768) Bytes2ObjectOpenHashMap is now used by RedisHash and RedisSortedSet for its map. This saves around 20 bytes per "hash" or "zset" instance. Bytes2ObjectOpenHashMap is derived from Object2ObjectOpenCustomHashMap so if you see some code in it that you question, compare it to the original. The class comment on Bytes2ObjectOpenHashMap describes the changes made to it. The goal was to keep the code as close to the original, but to make some changes to save on memory. Some cosmetic changes were also made using intellij automated cleanup (for example adding curly braces, getting rid of extra parens). Some new top level methods were added to allow users to avoid the overhead of creating a new instance when calling keySet(), entrySet(), or values(). These methods use to cache their result but no longer do to save on memory footprint. These new methods are named "fast*" and use the same pattern of some fast iteration code from the original Object2ObjectOpenCustomHashMap. > RedisHash and RedisSortedSet both use a hashMap that uses more memory than it > needs to > -- > > Key: GEODE-9497 > URL: https://issues.apache.org/jira/browse/GEODE-9497 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Both RedisHash and RedisSortedSet have an instance of > SizeableObject2ObjectOpenCustomHashMapWithCursor which can end up keeping > some objects alive that are not really needed. The memory used by these > object is currently not kept track of by geode's getSizeInBytes > implementation. > The objects referenced by these three fields are the problem: > # *entries* an instance of > it.unimi.dsi.fastutil.objects.Object2ObjectOpenCustomHashMap.MapEntrySet > # *keys* an instance of > it.unimi.dsi.fastutil.objects.Object2ObjectOpenCustomHashMap.KeySet > # *values* an instance of an anonymous subclass of > it.unimi.dsi.fastutil.objects.AbstractObjectCollection > > These fields get lazily initialized when their corresponding method is > called. Once they are initialized they stay that way forever. The object they > reference is immutable. Its only field is the implicit reference to its outer > class instance. Currently it looks like we have redis ops that can end up > calling all three of these methods in which case these objects would account > for over 100 bytes on a 64-bit jvm. > It is not clear to me why the implementors of Object2ObjectOpenCustomHashMap > chose to cache this immutable object instead of just creating it every time. > They have no state to initialize when constructed so one thing we could do is > override the methods that cache it to either null out the cached field after > calling the super method, or have the method ignore the super implementation > and just create and returns an instance without caching. The cache fields > themselves would be a waste of memory in that case but only 24 bytes (12 with > compressed oops). To avoid this waste of memory we could just create our own > subclass of AbstractObject2ObjectMap that does not have these three fields. > It looks like we might be able to get rid of some other fields (one of them > is to support null keys which we never use). If we go that direction we > should probably force byte array keys instead of have a generic parameter and > we could then get rid of the strategy field. > Another possibility would be for our code that uses the map to only call > entrySet(), that way one instance would be cached instead of 3. You can > always get keys and values from the entrySet. Even better would be to add the > methods we need to our subclass of Object2ObjectOpenCustomHashMap named > SizeableObject2ObjectOpenCustomHashMapWithCursor. We did this for scan to > have a stable cursor and we could do it easily for the places we need keys, > values, or entries. It would be easy to add the foreach style of method > directly on our subclass and use it in RedisHash. If we do this then we > should probably override the other methods to throw an exception to prevent > someone from accidentally using them in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9497) RedisHash and RedisSortedSet both use a hashMap that uses more memory than it needs to
[ https://issues.apache.org/jira/browse/GEODE-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9497. - Fix Version/s: 1.15.0 Resolution: Fixed > RedisHash and RedisSortedSet both use a hashMap that uses more memory than it > needs to > -- > > Key: GEODE-9497 > URL: https://issues.apache.org/jira/browse/GEODE-9497 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Both RedisHash and RedisSortedSet have an instance of > SizeableObject2ObjectOpenCustomHashMapWithCursor which can end up keeping > some objects alive that are not really needed. The memory used by these > object is currently not kept track of by geode's getSizeInBytes > implementation. > The objects referenced by these three fields are the problem: > # *entries* an instance of > it.unimi.dsi.fastutil.objects.Object2ObjectOpenCustomHashMap.MapEntrySet > # *keys* an instance of > it.unimi.dsi.fastutil.objects.Object2ObjectOpenCustomHashMap.KeySet > # *values* an instance of an anonymous subclass of > it.unimi.dsi.fastutil.objects.AbstractObjectCollection > > These fields get lazily initialized when their corresponding method is > called. Once they are initialized they stay that way forever. The object they > reference is immutable. Its only field is the implicit reference to its outer > class instance. Currently it looks like we have redis ops that can end up > calling all three of these methods in which case these objects would account > for over 100 bytes on a 64-bit jvm. > It is not clear to me why the implementors of Object2ObjectOpenCustomHashMap > chose to cache this immutable object instead of just creating it every time. > They have no state to initialize when constructed so one thing we could do is > override the methods that cache it to either null out the cached field after > calling the super method, or have the method ignore the super implementation > and just create and returns an instance without caching. The cache fields > themselves would be a waste of memory in that case but only 24 bytes (12 with > compressed oops). To avoid this waste of memory we could just create our own > subclass of AbstractObject2ObjectMap that does not have these three fields. > It looks like we might be able to get rid of some other fields (one of them > is to support null keys which we never use). If we go that direction we > should probably force byte array keys instead of have a generic parameter and > we could then get rid of the strategy field. > Another possibility would be for our code that uses the map to only call > entrySet(), that way one instance would be cached instead of 3. You can > always get keys and values from the entrySet. Even better would be to add the > methods we need to our subclass of Object2ObjectOpenCustomHashMap named > SizeableObject2ObjectOpenCustomHashMapWithCursor. We did this for scan to > have a stable cursor and we could do it easily for the places we need keys, > values, or entries. It would be easy to add the foreach style of method > directly on our subclass and use it in RedisHash. If we do this then we > should probably override the other methods to throw an exception to prevent > someone from accidentally using them in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408276#comment-17408276
]
ASF subversion and git services commented on GEODE-9486:
Commit 25f70a71d0b0c05b38dd383f2d9f36678c2b636b in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=25f70a7 ]
Revert "GEODE-9486: Fix validate-serializable-objects (#6746)" (#6816)
This reverts commit 3b2c5312d163f34701c3a01250491876942a6b48.
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9569) Geode Native User Guide build script: allow docs to be retained
Dave Barnes created GEODE-9569: -- Summary: Geode Native User Guide build script: allow docs to be retained Key: GEODE-9569 URL: https://issues.apache.org/jira/browse/GEODE-9569 Project: Geode Issue Type: Improvement Components: docs, native client Affects Versions: 1.13.4 Reporter: Dave Barnes The user guide build script allows the user to build and preview the geode-native user guides. A command-line option specifies whether the script generates the .NET or C++ user guide. When the script completes, it always deletes the generated guide. Allow the user to keep the compiled guide. Relevant files: geode-native/docs/docker/preview-user-guide.sh geode-native/docs/README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9568) Geode User Guide build script: allow doc to be retained
Dave Barnes created GEODE-9568: -- Summary: Geode User Guide build script: allow doc to be retained Key: GEODE-9568 URL: https://issues.apache.org/jira/browse/GEODE-9568 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.13.4 Reporter: Dave Barnes The user guide build script allows the user to build and preview the user guide. When the script completes, it always deletes the user guide. Allow the user to keep the compiled guide. Relevant files: dev-tools/docker/docs/preview-user-guide.sh geode-book/README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408244#comment-17408244 ] ASF subversion and git services commented on GEODE-9522: Commit e75dc7d47bea27c01bb021edfe768678f7d0e256 in geode's branch refs/heads/feature/GEODE-9522 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e75dc7d ] GEODE-9522: When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection. Co-authored-by: Barry Oglesby Co-authored-by: Anil > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9542: -- Labels: pull-request-available redis (was: redis) > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available, redis > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9522: -- Labels: pull-request-available (was: ) > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9522: - Summary: When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection. (was: Operations to replicate region were notified registered client in misorder due to switching primary queue ) > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7282) Geode Native Client .NET guide: Fix capitalization issues
[ https://issues.apache.org/jira/browse/GEODE-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408030#comment-17408030 ] ASF GitHub Bot commented on GEODE-7282: --- davebarnes97 opened a new pull request #863: URL: https://github.com/apache/geode-native/pull/863 Update method names to follow C# capitalization conventions. Addresses occurrences enumerated in the JIRA ticket - not a comprehensive survey of the entire user guide. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Geode Native Client .NET guide: Fix capitalization issues > - > > Key: GEODE-7282 > URL: https://issues.apache.org/jira/browse/GEODE-7282 > Project: Geode > Issue Type: Bug > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > Reviewer [~karensmolermiller] approved the Native Client manual > reorganization (GEODE-7262), but noted the following issues with the .NET > version. These need cleaning up. > geode-native/dotnet/111/regions/registering-interest-for-entries.html > - C++ capitalization in 3rd paragraph and in Client API for Registering > Interest > subsection > - I believe that all the examples use C++ capitalization > > geode-native/dotnet/111/serialization/data-serialization.html > - The .NET Example subsection has capitalization wrong for the field name > description. I think that the example was wrong before these docs were > separated, so this is not a mistake in separation. > > geode-native/dotnet/111/remote-queries.html > - Step 3 under Executing a Query from the Client should have a capital 'E' > in Query.Execute(). I think that the example was wrong before these docs were > separated, so this is not a mistake in separation. > > geode-native/dotnet/111/continuous-queries.html > - Prose within step 2 of Typical Continuous Query Lifecycle should change > to CqQuery Execute* methods (in 2 spots). Original prose only used the > C++ capitalization. Step 4 changes to CqQuery.Close. > - Prose within step 3 of Executing a Continuous Query from the Client > should change to CqQuery Execute* methods. > > geode-native/dotnet/111/function-execution.html > - This whole section was originally written with C++ capitalization. I suggest > that we introduce a separate task/PR to correct the capitalization for the > .NET docs. > > geode-native/dotnet/111/transactions.html > - first paragraph of Native Client Transaction APIs should capitalize Begin, > Commit, and Rollback, as they are function names. > - second paragraph of Running Native Client Transaction should capitalize > Begin, > Commit, and Rollback, as they are function names. > - There's a boo-boo in capitalization of the .NET Example. Within a foreach > code block, it should be > var value = GetValueFromExternalSystem(); > because function name start with a capital letter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
