[
https://issues.apache.org/jira/browse/GEODE-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101873#comment-17101873
]
ASF GitHub Bot commented on GEODE-8076:
---------------------------------------
dschneider-pivotal commented on a change in pull request #5019:
URL: https://github.com/apache/geode/pull/5019#discussion_r421647719
##########
File path:
geode-assembly/geode-assembly-test/src/main/java/org/apache/geode/rest/internal/web/controllers/PutKeyFunction.java
##########
@@ -30,6 +30,7 @@
private static final String ID = "PutKeyFunction";
+ @SuppressWarnings("unchecked")
@Override
Review comment:
I have removed this change. I don't know how it snuck in. It caused a
bunch of merge conflicts. The build is fine without this change. If someone
wants to clean this test code up I think it should be on another PR.
##########
File path:
geode-assembly/geode-assembly-test/src/main/java/org/apache/geode/rest/internal/web/controllers/GetAllEntries.java
##########
@@ -29,6 +29,7 @@
public class GetAllEntries implements Function {
+ @SuppressWarnings("unchecked")
Review comment:
I have removed this change. I don't know how it snuck in. It caused a
bunch of merge conflicts. The build is fine without this change. If someone
wants to clean this test code up I think it should be on another PR.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> simplify redis concurrency code
> -------------------------------
>
> Key: GEODE-8076
> URL: https://issues.apache.org/jira/browse/GEODE-8076
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Major
>
> Currently when doing a redis set operation, for example sadd, the code has to
> be careful to deal with other threads concurrently changing the same set.
> It does this in a number of ways but this could be simplified by having a
> higher level layer of the code ensure that for a given redis "key" operations
> will done in sequential order.
> This can be done safely in a distributed cluster because we now route all
> operations for a given key to the server that is storing the primary copy of
> data for that key.
> I spike was done and we found that this form of locking did not hurt
> performance. Since it allows simpler code that is less likely to have subtle
> concurrency issues we plan on merging the work done in the spike into the
> product.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
