On Sun, Sep 4, 2011 at 22:12, Brett Hoerner <[email protected]> wrote: > On Sun, Sep 4, 2011 at 7:05 PM, Greg Stein <[email protected]> wrote: >> 1. I'd like Riak to generate keys for some of my objects, and I'm >> using the HTTP API. Pretty simple: do a POST, and the Location: header >> will tell me the key. However, looking at the code... it doesn't >> appear that object.store() actually reads and returns that key. Am I >> missing something here? Maybe there is a Proper Way to do this? > > You're right, it looks like this functionality was added without the > logic to pull the key back out of the response. It definitely should.
Okay. Just wanted to make sure that I wasn't missing something. I'll craft up a patch. >... >> 2. The HTTP transport code doesn't use httplib properly at all. When I >> wrote the httplib library, my primary design point was to enable >> persistent, HTTP/1.1 connections. That was the whole idea behind >> HTTPConnection. The transport library opens a *new* connection for >> every request. I'm not surprised that the performance suffers, since a >> TCP setup handshake needs to occur on every request. ... So: are there >> any plans to rebuild the HTTP support to use persistent connections? > > I believe I've read that Riak itself doesn't support keep-alive. > Someone else would have to comment for sure here. Regardless, this > feature would be handy because many people use Riak over HTTP through > a reverse proxy. It looks like Riak supports persistent connections, according to this post: http://lists.basho.com/pipermail/riak-users_lists.basho.com/2010-March/000744.html I'd like to understand if there is a roadmap for the HTTP client, and if >> 3. The Luwak support reads the *entire* "file" into memory. My >> understanding is that Luwak is for "large" files. If those files are >> (say) a gigabyte, then the current code is going to impact clients in >> a *very* bad way. I can see that the code wants to read the response, >> then return the connection back to the pool... but that just isn't >> workable. A connection needs to be held by the reader, which then >> streams it to completion (or close), and only then should the >> connection be returned. Now, if Luwak is defined for files less than >> (say) 10 megabytes, then maybe this approach isn't wrong, but I >> haven't seen any documentation about size limitations. Any thoughts on >> this? > > You're 100% right that it should spool to disk, Luwak is meant for > very large files. I see no reason to spool to disk. Just keep the socket open, and let the application read as necessary. That said, thanks for validating my understanding of Luwak files. > The Python client has been pretty quiet in my experience (though I > only started messing with it about a month ago). I'm sure patches for > any/all of the above are welcome. I'm hoping the Basho guys have > someone on it to review pull requests and such sooner than later. Can do. I've already submitted a pull request to allow the client to work with older versions of Python (e.g the Python 2.5 installed on my Mac OS Leopard laptop). Cheers, -g _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
