beta3 built from source does not listen on port 11211

Hi Jacob, thanks for the feedback...I'll be looking into that and get back to you.

For my own curiosity, is there a specific need to build your own RPM's?
Thanks

Perry

I would be happy to send along our spec files if they might be helpful. They are still a little rough around the edges, and they are very RHEL5-specific (we do not use EPEL, or whatever NS is using to get a newer autoconf, for example).

I would be happy to share what I have completed so far; I am attaching a zip archive with the spec files I am currently using for RHEL5.

Back on the main question I have, if I start membase and then also try to start moxi directly with the same args, it outputs the following repeatedly:
ERROR: could not contact REST server(s): [url]http://127.0.0.1:8080/pools/default/saslBucketsStreaming[/url]

I can connect to the URL myself, but only if I specify a username and password (the one I gave for the administrative console works). How is moxi supposed to find out the username and password to use?

Jacob, you can supply Moxi with a password using the "-Z" command line so that it looks like this: "./moxi -Z usr=,pwd= "

I've already filed a bug to make it clearer and easier to supply a password ([url]http://bugs.northscale.com/show_bug.cgi?id=2275[/url])

Thanks for your feedback, I'm still working on a response for the licensing issues but I am certainly glad that you are using and testing Membase in whatever form works best for you.

Thanks

Perry

Hi Perry,

Thanks for the info about starting moxi with username and password info. I will test that out soon. Unfortunately, it does not completely solve the issue because membase is internally starting moxi without that information. The moxi commandline at the top of this thread is the full commandline of a running moxi process started internally by membase.

Also of course, there is an additional issue that starting moxi with credentials on the commandline presents a potential ps information leak to local users.

Thanks,
-Jacob

I think I've been headed in the wrong direction with this. I added the attached patch to libconflate and then rebuilt moxi. Here is the actual error coming from curl:

[jacob@rhel5x86-64 ~]$ moxi -Z port_listen=11211,downstream_max=1 -z url=http://127.0.0.1:8080/pools/default/saslBucketsStreaming -p 0 -Y y -O stderr
2010-09-05 15:03:30: (memcached.c.4521) moxi log, mode=1, file=(null)
WARNING: curl error: Couldn't resolve host '
?Y+'
ERROR: could not contact REST server(s): [url]http://127.0.0.1:8080/pools/default/saslBucketsStreaming[/url]
WARNING: curl error: Couldn't resolve host '?vT'
ERROR: could not contact REST server(s): [url]http://127.0.0.1:8080/pools/default/saslBucketsStreaming[/url]
WARNING: curl error: Couldn't resolve host '?vT'
[...]

So probably the issue is with the curl integration.

Ok, I tracked the above issue down. It was kind of a pain since there's been so much drift in libconflate/rest.c since beta2. I think it is essentially a curl bug, but this bug is in RHEL5 so hopefully you'll work around it. The 'url' pointer being passed to curl is freed before curl uses it. The sequence of events is as follows:
1) in setup_handle a new buffer named url is created
2) in setup_handle url is passed to curl_easy_setopt
3) in setup_handle url is freed
4) in run_rest_conflate curl_easy_perform is called, tries to read the value of its copy of url, but the memory has been freed and it gets garbage instead

Unfortunately for me, resolving this issue does not seem to have resolved the problem. moxi still does not listen on port 11211.

Actually it did resolve the port issue. I just needed to also fix the userpasswd variable. I have attached a patch to resolve both problems.

Now I'm on to new problem (SERVER_ERROR proxy write to downstream) but I'll start a different query if I can't figure that out on my own.

Thanks,
-Jacob

Ok, I figured this out as well. I needed to get everything using isasl (somewhat a pain with older autoconf) and force ep.so to be linked against sqlite3.

Thanks so much for working this through Jacob, this is a prime example of our need to make things easier and clearer and your efforts will not be in vain.

Let me know how else I can help you.

Perry

Thanks so much for working this through Jacob, this is a prime example of our need to make things easier and clearer and your efforts will not be in vain.

Let me know how else I can help you.

Perry

I have been hoping to see this second libconflate patch show up in the git repository... It is technically a bug in the libconflate code. If you refer to the following API document:

[url]http://curl.haxx.se/libcurl/c/curl_easy_setopt.html[/url]

You will see: "Before version 7.17.0, strings were not copied. Instead the user was forced keep them available until libcurl no longer needed them."

In other words, the current libconflate code is only valid for curl versions 7.17.0 or newer. RHEL5 uses 7.15.5. The patch I provided resolves this issue by moving the variables passed to curl into a scope where they will outlive the curl invocation.

Thanks for following up Jacob. I have passed that over to our engineering group and filed bug 2364 ([url]http://bugs.northscale.com/show_bug.cgi?id=2364[/url]) to track and prioritize this.

Do you have the ability or desire to submit this change yourself?

Perry

Hi Perry,

I don't have time to wade through getting a github account right now, so it might be faster if NS wants to just grab the patch attached to comment 10 in this thread.

Thanks,
-Jacob

Makes sense Jacob, just wanted to float the idea. I've already brought it up internally.

Thanks!

Perry