Open tleyden opened 9 years ago
Also, I think there should be a comment explaining why atomic.StorePointer() is being used here
This should have been flagged in code review.
@tleyden Thanks for following up with this. We are chomping at the bit to use Couchbase, especially given the awesome GKE tutorial. https://github.com/couchbase/kubernetes Our cluster is up, running and just begging for some data. :)
+1 on this! We're in the same boat!
@tleyden We use an unsafe pointer here to avoid using a mutex (sync.Lock) . When the bucket is refreshed we need to atomically update the local copy of the vbucket map and the node list to avoid a race condition.
So the value add of the unsafe pointer is strictly performance?
That is correct.
It looks like there are deeper issues beyond just unsafe, based on Brett's comment from the linked issue.
Hey Derek, Unfortunately, there are actually further complications in terms of making gocb compatible with the App Engine runtime platform. The most integral one being that we communicate with the Couchbase cluster through the use of sockets, which are disallowed inside of the App Engine runtime. Additionally, the App Engine Go runtime runs inside of a strange kind of environment where each request being handled is effectively run from its own 'process'. This means that the ability to persist the connection to Couchbase across multiple requests is lost, and this would severely affect performance of your application (Couchbase has a relatively high cost-to-connect). Cheers, Brett
See https://issues.couchbase.com/browse/GOCBC-38 -- users cannot run this on Google App Engine since packages that use "unsafe" is forbidden.
This repo has the same issue. Is using unsafe absolutely required?