Halo!

Sorry for the delay! I've been on vocation again :P

I'd like to write some quick notes below regarding your code sample.

On Sun, Jun 5, 2011 at 2:15 AM, gregr401 <nginx-forum@nginx.us> wrote:
>
> location /mytest {
>                content_by_lua '
>                        local replies = ngx.location.capture("/redis2")
>                        local parser = require("redis.parser")
>                        -- assuming the replies variable holds n redis
> responses
>                        -- to be parsed:
>                        -- tried this in case n needed set:  local
> results = parser.parse_replies(replies, 2), same error
>                        local results = parser.parse_replies(replies,
> n)

Here, you assumed that ngx.location.capture() returns response body
directly, which is not the case. The ngx.location.capture() returns a
Lua table which has three slots, header, body, and status. See
ngx_lua's README for more details.

So here you should write

local res = ngx.location.capture("/redis2")
if res.status ~= ngx.HTTP_OK then
ngx.exit(res.status)
end

local results = parser.parse_replies(res.body, 2) -- 2 pipelined
requests in /redis2

> ## results in 500 and below error snippet
>
> I see the following in the error log:
>
>  [error] 4921#0: *3 lua handler aborted: runtime error: [string
> "content_by_lua"]:6: attempt to call field 'parse_replies' (a nil value)
> while sending to client  request: "GET /mytest HTTP/1.1"
>

This error implies that you're using a too old version of the
lua-redis-parser library which does not support the parse_replies
function at all. The latest tagged version of lua-redis-parser was
v0.04, which does not include the pipelining feature implemented in
master HEAD. I'm guessing you were using that.

I've just tagged master HEAD as the v0.05 release that you can download below:

https://github.com/agentzh/lua-redis-parser/downloads

>
> On a separate note, I've noticed when using Maxim's wonderful keepalive
> upstream module between redis, an established connection that performs a
> redis AUTH will actually maintain that 'authed' state for any subsequent
> redis calls (even those with no specific AUTH call).   I'd imagine these
> will work till the connections eventually timeout, keep this in mind
> when testing when using redis && auth.
>

Well, you cannot rely on that because you cannot really control how
and when the connection pool opens and closes connections.

For similar reasons, ngx_drizzle implements the charset option all by
itself on the C level by ensuring "set names 'some_charset'" was sent
to mysql exactly once for a connection. It does not use
ngx_http_upstream_keepalive, rather, its own connection pool
implementation, so it is possible.

Regards,
-agentzh

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx