do I need a new instance of memcached for each instance of reviewboard?

[Eric Johnson]

I've got multiple instances of reviewboard (version 1.5.7) running on the same server (so that I can sandbox the users so that there's no risk of them seeing code from other code repositories that they don't have access to.

I'm only using one instance of memcached, though. Do I need a separate instance of memcached for each instance of reviewboard?

-Eric.

[Christian Hammond]

One is fine. The keys will be prefixed with the server's configured domain in order to prevent conflicts.

You'll just want to bump up the memory allocation for memcached as high as you can go. A good rule in general, but even more important when you have many instances using it.

I should point out though that in 1.6.x, Review Board can keep review requests and code restricted to certain groups/users. So there's less need to run multiple servers.

Christian

--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

-Eric.

--
Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to reviewboard...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en

[Eric Johnson]

Hi Christian,

Thanks for the quick response. I should have added crucial details - I'm hosting all these reviewboard instances with the same DNS name, but just a different path, as in:

http://myhost.example.com/rbinstance1/
http://myhost.example.com/rbinstance2/

(the above being examples, of course, not my actual host or path). When you say "the server's configured domain", exactly where is this configuration, so that I can verify that it is distinct amongst these ReviewBoard instances?

I asked the question because I've seen cache leakage - someone using "rbinstance2" sees a diff applied to source code from "rbinstance1". Restarting memcached fixed the problem, at least temporarily, so it is definitely something related to cache, rather than my configuration. I've seen this problem once before, but that was perhaps a year ago, and using 1.5.0, not 1.5.7, and several updates to memcached ago. Of course, now I'm using 1.5.7, with the latest stable version of memcached on Gentoo, so something else is going on.

As for the features of 1.6.x, I'm aware of the changes. Unfortunately, we deployed before they were available, and needed isolation between instances. Without a way to merge instances, we're unlikely to switch to use ReviewBoard's built-in approach for security.

-Eric.

[Christian Hammond]

Hi Eric,

Ah, yes, in this case you may be stuck. We use the actual domain name specified for the site, which in your case is being duplicated, hence the leakage.

This code lives in Djblets's djblets/util/misc.py. Look at make_cache_key.

One thing that could be done is to have that function check if settings has the SITE_ROOT attribute set, and if so, include that as part of the key prefix. If you'd like to try modifying your copy of djblets to do this and test it, we can get that in for a release.

Christian

--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

[Eric Johnson]

Hi Christian,

I filed bug http://code.google.com/p/reviewboard/issues/detail?id=2538 about this issue, and put a patch into the comment.

I validated my change by turning on logging, adding a line to show the key being generated, and then running reviewboard. That confirmed that my fix added the SITE_ROOT into the key.

Please let me know if you need anything more to apply this.

Thanks for the pointers that got me looking in the right place.

-Eric.