possible to check if socket has data to be read without reading it?

ryan · 2015-11-17T06:52:49+00:00

Thanks. I was trying to prevent multiple queries and update to lru/shared cache when cache expires. may be not worth it.On Monday, 16 November 20...

possible to check if socket has data to be read without reading it?

ryan

Hi,

I'm looking to be able to check if a socket has data without reading from it? Is this possible? Ideas for a patch to enable this if not? It seems like nginx should be aware if the socket has data to be read.

Thanks

agentzh

Hello!

On Tue, Nov 17, 2015 at 6:52 AM, Ryan Zenker <r...@nodal.org> wrote:
> I'm looking to be able to check if a socket has data without reading from
> it?  Is this possible?  Ideas for a patch to enable this if not?  It seems
> like nginx should be aware if the socket has data to be read.
>

If the LuaSocket library has such a method for peeking, then we can
implement that method in cosockets. Failing that, the "peek" method
name looks good to me. Patches welcome.

I'm curious about your use case though. Why do you need this?

Regards
-agentzh

ryan

There are cases when using lua-resty-http and the server short circuits a error response we don't get it because stuck in a send loop that is now blocked by the server. One idea was to do something like this in the send loop to detect if the server is responding and cancel the rest of the request body and go grab the response.

On Monday, November 16, 2015 at 9:16:50 PM UTC-5, agentzh wrote:

Hello!

On Tue, Nov 17, 2015 at 6:52 AM, Ryan Zenker <ry...@nodal.org> wrote:
> I'm looking to be able to check if a socket has data without reading from
> it? Is this possible? Ideas for a patch to enable this if not? It seems
> like nginx should be aware if the socket has data to be read.
>

If the LuaSocket library has such a method for peeking, then we can
implement that method in cosockets. Failing that, the "peek" method
name looks good to me. Patches welcome.

I'm curious about your use case though. Why do you need this?

Regards
-agentzh

agentzh

Hello!

On Wed, Nov 18, 2015 at 1:13 AM, Ryan Zenker wrote:
> There are cases when using lua-resty-http and the server short circuits a
> error response we don't get it because stuck in a send loop that is now
> blocked by the server.  One idea was to do something like this in the send
> loop to detect if the server is responding and cancel the rest of the
> request body and go grab the response.
>

I don't really follow you but it seems to me that this can be achieved
more elegantly and reliably with ngx.thread.spawn and ngx.thread.kill.

Regards,
-agentzh

ryan

Yeah, that is probably the best way to handle it. Thanks

On Tuesday, November 17, 2015 at 1:00:44 PM UTC-5, agentzh wrote:

Hello!

On Wed, Nov 18, 2015 at 1:13 AM, Ryan Zenker wrote:
> There are cases when using lua-resty-http and the server short circuits a
> error response we don't get it because stuck in a send loop that is now
> blocked by the server. One idea was to do something like this in the send
> loop to detect if the server is responding and cancel the rest of the
> request body and go grab the response.
>

I don't really follow you but it seems to me that this can be achieved
more elegantly and reliably with ngx.thread.spawn and ngx.thread.kill.

Regards,
-agentzh