Using Membase Client with a Membase Server w/bucket-type: Memcached

Hi,

Can you please paste the code snippet of how you access Membase from your client?

Thanks

Bhawana

 does your app pool identity have network access? how is your firewall configured?

Thanks for the answers. Yes, the app pool identity does indeed have network access.

Here's my code snippet:

string key="testKey";
string value = "testValue";

using (Membase.MembaseClient mc = new Membase.MembaseClient()) {

bool result = mc.Store(StoreMode.Set, key, value);

value = mc.Get(key);

}

The first operation hangs for like 10 secs then returns FALSE.

The second hangs for like 10 secs and then returns NULL (which might sound pretty obvious if you watch the code considering the fact that the corresponding Store() didn't work: but since I have full access to that same Membase Server with a standard enyim memcached client I also tried with a valid/present key... with the same NULL result. So I think I can say that both methods ain't working in my scenario ).

The configuration is exactly like stated in my previous post.

A thing i noticed is that if i remove (or modify) the userName/password part from the <servers> tag the two operations don't hang and immediatly returns their value: that makes me think that it's probably something subsequent to the client/server authentication part, which seems to succeed.

I also want to point out that the standard memcached client, with the app.config file configured accordingly (no buckets-aware config, with <enyim.com> sectionGroup, etc.) correctly works and I'm currently using it in my website with great results, so I don't think it can be a server problem.

I just don't know why the bucket-aware Membase client is not working....

Hi again,

I downloaded the source code of the Membase Client 2.10 and fully debugged my test application, and I finally think I've figured it out.

I'm trying to explain the situation so it can be helpful for other users too.

Basically, my 4 Membase Servers see each other using a dedicated 1GB LAN which has their own IP addresses/subnet mask:

ns_1@192.168.110.101
ns_1@192.168.110.102
ns_1@192.168.110.103
ns_1@192.168.110.104

My application can reach them using another LAN, which has different permissions and IP addresses:

192.168.120.101
192.168.120.102
192.168.120.103
192.168.120.104

While the standard memcached configuration allows the client to call directly the servers using the correct, allowed IP address (192.168.120.101:11211), the membase configuration seems to retrieve the internal cluster IP addresses, which in my scenario are intended to be behind-the-scene. I've seen this in the JSON result of the http://192.168.120.101:8091/pools/default call, which contains:

[...] "hostname":"192.168.110.101:8091" [...] "hostname":"192.168.110.102:8091" [...]  and so on.

Those "unauthorized" (in my scenario) IP addresses are placed in the endPoint of each MemcachedNode and then used to make the actual request: that's why the Socket initialized in the PooledSocket.cs class of Enyim.Caching.dll fails to initialize and the whole process timeouts.

I added a simple "ignoreServerHostnames" configuration property and modified the code to valorize the endPoint property of the MemcachedNodes with the IP used in the <servers> app.Config element, and now it seems to work. I can send you the small code changes if you're interested in implementing this feature and/or discuss the matter with you.

Anyway, thanks a lot for your support and keep up the great work, I've seen the whole code and found it brilliant.

Take care,

 if you can submit your changes as a pull request on github then i can have a look at them.

on the other hand i think this is an issue which should be addressed by the membase team. why? because if i understand your description correctly you defined all your servers in the app.config and then you use that list instead of the one returned by the config server. and as soon as you add a new node to your cluster that node will appear in the configuration sent by the cluster, but you'll not recognize that you need to use a different IP address for it.

You're absolutely right, I also consider it a mere workaround rather than a proper fix. A more accurate solution might be, for example, to pass that property value to the server and make it replace the hostname value in the actual response with the IP address used by the caller when it's set to TRUE.

That said, coming from a "memcached" scenario, it's fair to me to manually have to specify every single server cluster's node so I'm quite happy to got it solved.

I hope that this discussion will be useful for the Membase Server development team and for everyone who had encountered my same issue.

 Thank you for your time and keep up the great work!

 Attila/Dark, thanks so much for working through this.

Another workaround is to use the instructions listed on this page to force the Membase servers to identify themselves via a specific IP address: http://wiki.membase.org/display/membase/Using+Membase+in+the+Cloud

Let me know how that works out for you.

Perry

Nice post for me , tnx ! viagra!