Bug 801519
| Summary: | Configuration of asynchronous replication affects communication between HotRod client and a cache | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Martin Gencur <mgencur> |
| Component: | unspecified | Assignee: | Tristan Tarrant <ttarrant> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.0.0 | CC: | jdg-bugs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-03-09 07:12:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Martin Gencur
2012-03-08 17:59:42 UTC
I'm closing this because the test is not correct. It uses HotRod client in conjunction with REPL mode which does not make sense IMHO. queue-size and queue-flush-interval seem to work fine when using memcached client. Martin Gencur <mgencur> updated the status of jira ISPN-1466 to Closed Martin Gencur <mgencur> made a comment on jira ISPN-1466 See the explanation in RH Bugzilla integration comment. Martin Gencur <mgencur> made a comment on jira ISPN-1466 The test was indeed incorrect but using HotRod client in conjunction with REPL mode makes sense. The requests are then dispatched to the servers in a round-robin manner. (as described here: https://docs.jboss.org/author/display/ISPN/Java+Hot+Rod+client - Request Balancing). Manik Surtani <manik.surtani> updated the status of jira ISPN-1466 to Reopened Manik Surtani <manik.surtani> updated the status of jira ISPN-1466 to Resolved Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 @Martin, for async caches, it might make sense to have a first available, or sticky, load balance policy because round-robin could throw funny results. Isn't that what you meant? Martin Gencur <mgencur> made a comment on jira ISPN-1466 No... as I now know that the round-robin is used by default when using HotRod client and REPL mode, the failure I got was making sense. I was storing a key/value via HotRod and subsequently did this assert: assertTrue(null != asyncCache1.get("k1")), but since it was configured for ASYNC and used round-robin, the assertion actually tried to find a key in another node than where I stored the key (and the replication did not take place yet) so I got null value. And this is expected IMO. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 @Martin, sure it's expected but it's rather confusing for the user. If the cache is configured with ASYNC (repl or dist), it should use a sticky node like load balance policy, where all requests for the same key get directed to the same node. The problem is that the client is not aware of the cache configuration, but it'd be nice in the future for the server to be able to provide hints to the client. In the absence of these hints, if the client developer knows that it's gonna talk to an async cache, it should be able to configure the load balance policy to be sticky-per-key in order to avoid the issue you had. I'm not aware of such LBP for REPl (dist does it by default, I think, by always going to the 1st owner of the key) so maybe we should implement it. Also, not sure if LBP can be configured on a per cache basis either. Martin Gencur <mgencur> made a comment on jira ISPN-1466 Yes, it would be nice to have something like the sticky-per-key policy for ASYNC caches in REPL mode. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-1466 Martin, I've created ISPN-1916. |