We see some value in enabling replica reads in Couchbase AspNet to increase availability in the event of a failed node. Is this on the roadmap and/or something you’d consider including if we provided a PR?
@unhuman -
I agree perhaps making it an optional? Would you mind making a feature request on the project’s Jira? By creating the ticket you’ll be added as a watcher and be alerted when it’s status changes.
If you want to push a pull-request, go for it, even if it’s not accepted it gets the ball rolling!
-Jeff
1 Like
@unhuman -
I created the ticket here. The only caveat is that this would only work with couchbase (persistent) buckets, since only they have replicas.
-Jeff
1 Like
Thanks! Definitely should be optional. We want replication for our Sessions to improve availability.
I’ve started to play around with this (replica reads), and it doesn’t seem to be as trivial as I thought. Rather than permitting the web page to fast-fail, the timeouts come into play and if there’s multiple read attempts per page, it can really hurt page load times. This is easily exposed by the test application included with the AspNet; for each page, there are 4 read requests.
When the node is first turned off, it takes only a few seconds for the Get to return a Timeout. After a while, they get ridiculously long. I do not yet know why, but the Get takes minutes to timeout for each request to timeout. In my most recent timing, it was 4 minutes. The page, however, does not come back to query for a while. Also, note this seems to affect reads after a little while with the non-modified client as well. All I do is have a 2 node cluster running and shut down one of the nodes. I’d guess there are some other issues too, since exclusive access is off…
In our testing, the Couchbase AspNet appears to be performing pretty well compared to our existing solution. We did, however, need to up the Disk I/O Optimization on the bucket to high. For frequently trafficed sites, that might be a good recommendation.
In CouchbaseSessionStateProvider.cs / Save(), I noticed:
> // Now save the data
.... // Attempt to save the data and fail if the CAS fails
But, there is no failure handling in that case.
Finally, is there an ETA date for a non-beta / GA library?
@unhuman -
It gets tricky - the trade off is availability for performance and you end up introducing a lot of latency.
Looks like a bug, i’ll create a Jira ticket.
Likely sooner than later now that Couchbase 4.0 is GA. I’ll work on planning a GA date in Jira, I am going say tentatively early November or December of this year, but no promises ATM!
-Jeff
Jeff,
Please notice the general issues I’m seeing (regardless of my changes) when a node is down. Timeouts just don’t appear to be respected… This could bring down our entire app if a node fails for any reason, it seems.
Thanks for the quick reply.
-H
@unhuman -
Would mind creating a Jira ticket for each issue you found with description and steps to reproduce? You will get alerts once the status changes on them.
The project is here: https://issues.couchbase.com/browse/CBASP
Thanks,
Jeff
Will do. Thanks. This is pretty high profile for me right now. Couchbase everywhere!
1 Like
@jmorris It looks like the bug with timeouts not being respected was fixed somewhere between 2.1.0 and 2.1.4… 2.2.0 also has whatever fixed this.
The beta AspNet depends on 2.1.0, so I figured just try that out…
This sound like something you meant to fix? 
Can you provide an update on ETA for the release of Couchbase AspNet?
BTW - In our testing it seems to have done pretty well. We did up our bucket disk I/O priority to High. That made a big difference for us.
1 Like