[ANN] lua-resty-validation 2.0

aapo.talvensaari · 2015-10-10T21:05:58+00:00

I have set oscp response data to my shared memory for updating after 7 days, but I find the ocsp response info show it will update for 2 days, Since I...

[ANN] lua-resty-validation 2.0

aapo.talvensaari

Hi all,

Let me announce that I have just released lua-resty-validation 2.0. This is total rewrite for the previous 1.0 version and the versions are not compatible in any way.

I think that I have finally found a neat way to do this tedious validation work that you usually need on web applications. I have also written a lot more docs that you can read from here:

https://github.com/bungle/lua-resty-validation

I would like to get feedback for this, and if you think that you can contribute more validators either as extensions (banking, postal, etc.) or as built-in validators, please send me suggestions or even pull-requests. The base is quite good now to build upon.

This library works also with plain Lua and LuaJIT.

Regards

Aapo

erik.l.nelson

lua-resty-lock has a good example of updating a cache from a synchronous service like redis, something like

local val = fetch_redis(key)
....
local ok, err = cache:set(key, val, 1)

I have a slightly different twist on this problem- when I need a cache update, the light thread can only initiate the cache update process, and the updated information will be returned asynchronously through a different HTTP call.  My current solution is polling, something like this pseudocode, adapted from the lua-resty-lock example starting at fetch_redis()

begin_async_update()

while true do
  -- check to see if async process called in to location '/update_cache?value=new_cache_value', possibly in a different worker
  if async_update_happened() then break end
  ngx.sleep(1)
end

This works okay but it feels inelegant- is there some way to write a condition-variable-like statement, so something like the below could be written?  Any suggestions would be welcome.


begin_async_update()
local result = condition_var.wait(timeout)
if result then --wait was successful, new value is available
...
end

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

agentzh

Hello!

On Tue, Oct 13, 2015 at 12:29 AM, Nelson, Erik - 2 wrote:
> lua-resty-lock has a good example of updating a cache from a synchronous service like redis, something like
>
[...]
>
> I have a slightly different twist on this problem- when I need a cache update, the light thread can only initiate the cache update process, and the updated information will be returned asynchronously through a different HTTP call.  My current solution is polling, something like this pseudocode, adapted from the lua-resty-lock example starting at fetch_redis()
>

Sorry, I don't understand. If your main light thread *has to* wait for
the result of the asynchronous operation, why not just do a
synchronous operation? Is that asynchronous operation runs outside the
current context? Like in another request handler or per-worker timer
thread?

In the context of OpenResty, synchronous operations are doing
nonblocking operations per se as long as you're stick with OpenResty's
APIs. Thus you are safe with I/O performance even with synchronous
paradigm (actually that's one of the selling points of OpenResty).

> begin_async_update()
>
> while true do
>   -- check to see if async process called in to location '/update_cache?value=new_cache_value', possibly in a different worker
>   if async_update_happened() then break end
>   ngx.sleep(1)
> end
>

I wonder how you check if an update has happened? Polling a remote
endpoint via something like HTTP anyway?

> begin_async_update()
> local result = condition_var.wait(timeout)
> if result then --wait was successful, new value is available
> ...
> end

I wonder who will be responsible to update the condition_var above for
you. That's why I ask how you check for updates.

FWIW, there will be a new semaphore API added soon to ngx_lua, which
allows efficient synchronizations between light threads running in the
same nginx worker process (not necessarily be in the same request
context though). Not sure if you want something like that. My gut
feeling is that you can just do nonblocking synchronous update anyway
if that is possible.

Regards,
-agentzh

erik.l.nelson

Yichun Zhang (agentzh) wrote on Tuesday, October 13, 2015 11:07 AM
> 
> On Tue, Oct 13, 2015 at 12:29 AM, Nelson, Erik - 2 wrote:
> > lua-resty-lock has a good example of updating a cache from a
> > synchronous service like redis, something like
> >
> [...]
> >
> > I have a slightly different twist on this problem- when I need a
> cache
> > update, the light thread can only initiate the cache update process,
> > and the updated information will be returned asynchronously through a
> > different HTTP call.  My current solution is polling, something like
> > this pseudocode, adapted from the lua-resty-lock example starting at
> > fetch_redis()
> >
> 
> Sorry, I don't understand. If your main light thread *has to* wait for
> the result of the asynchronous operation, why not just do a synchronous
> operation? Is that asynchronous operation runs outside the current
> context? Like in another request handler or per-worker timer thread?

Yes, exactly- an external program actually needs to do the operation, and calls another request handler when it's done.

> 
> In the context of OpenResty, synchronous operations are doing
> nonblocking operations per se as long as you're stick with OpenResty's
> APIs. Thus you are safe with I/O performance even with synchronous
> paradigm (actually that's one of the selling points of OpenResty).
> 
> > begin_async_update()
> >
> > while true do
> >   -- check to see if async process called in to location
> '/update_cache?value=new_cache_value', possibly in a different worker
> >   if async_update_happened() then break end
> >   ngx.sleep(1)
> > end
> >
> 
> I wonder how you check if an update has happened? Polling a remote
> endpoint via something like HTTP anyway?
> 

I'm checking the value in a lua_shared_dict that is only updated by the /update_cache request handler.

> > begin_async_update()
> > local result = condition_var.wait(timeout) if result then --wait was
> > successful, new value is available ...
> > end
> 
> I wonder who will be responsible to update the condition_var above for
> you. That's why I ask how you check for updates.
> 

In this case, the /update_cache handler would update the condition_var, similar to the way that it updates the lua_shared_dict currently.  The main advantage of the condition_var is that the waiting thread can run immediately when the condition_var is triggered.

> FWIW, there will be a new semaphore API added soon to ngx_lua, which
> allows efficient synchronizations between light threads running in the
> same nginx worker process (not necessarily be in the same request
> context though). Not sure if you want something like that. My gut
> feeling is that you can just do nonblocking synchronous update anyway
> if that is possible.

I think that won't help with this particular problem but would still be quite a useful tool, as it sometimes could be useful to allow light threads to have more insight into each others' operations.

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

erik.l.nelson

Yichun Zhang (agentzh) wrote on Tuesday, October 13, 2015 11:07 AM
> On Tue, Oct 13, 2015 at 12:29 AM, Nelson, Erik - 2 wrote:
> >
> > I have a slightly different twist on this problem- when I need a
> cache
> > update, the light thread can only initiate the cache update process,
> > and the updated information will be returned asynchronously through a
> > different HTTP call.
> 
> Sorry, I don't understand. If your main light thread *has to* wait for
> the result of the asynchronous operation, why not just do a synchronous
> operation? Is that asynchronous operation runs outside the current
> context? Like in another request handler..?
> 

I might not have said it clearly, but a programming construct that allows one light thread to wait on another request handler (potentially in a different worker) is exactly what I was hoping for.

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

agentzh

Hello!

On Wed, Oct 14, 2015 at 12:18 AM, Nelson, Erik - 2 wrote:
>
> I might not have said it clearly, but a programming construct that allows one light thread to wait on another request handler (potentially in a different worker) is exactly what I was hoping for.
>

This is not possible right now but I think it's doable in the future.
To think aloud, one possible solution is to use datagram (unix) domain
socket pairs. To make this concrete, the waiting request handler (or
the subscriber) does these:

1. creates (or just reuses one from a local socket pool) a datagram
unix domain socket (or a local UDP socket) and register its name (or
port number) to the shm with a unique key, and then
2. initiates the async external backend (update) request,
3. read on the socket using the nonblocking cosocket API until
receiving the results from the publisher, and finally
4. put the socket into a pool for later reuse (by the same request
handler or any other request handlers in the same worker)

At the same time, the external service invokes a publishing (HTTP)
endpoint exposed by the same nginx server instance. The publishing
handler in the nginx does the following

1. retrieve the key (originally generated by the subscriber) from the
external publisher, as well as the results the subscriber wants, and
then
2. use the key to lookup the shm to find the socket address info, then
3. write to the socket with the result data got in step 1 above.

Of course, we need to expose a bind() method in the current
UDP/datagram cosocket API to make this work. Patches welcome :)

The core idea in this proposal is to use sockets as a synchronous
nonblocking inter-process lock as well as a data transfer channel.

Best regards,
-agentzh

agentzh

Hello!

On Wed, Oct 14, 2015 at 11:41 AM, Yichun Zhang (agentzh) wrote:
> To think aloud, one possible solution is to use datagram (unix) domain
> socket pairs. To make this concrete, the waiting request handler (or
> the subscriber) does these:
>

Oh, we can have a more efficient approach using the socket pairs like below:

1. Each worker has only one such listening socket.
2. Each worker runs a background light thread created by
ngx.timer.at() that continuously reads from the socket any new
messages and then dispatch the messages to individual subscribers via
the ngx.semaphore API.
3. Each subscriber thread waits on the semaphore.
4. The external service calls a publishing endpoint that writes to the
correct worker process's listening socket.
5. The key should included in the messages for the dispatcher described in 2).

This can save a lot of sockets in case of large number of subscribers.
No extra sleeping delays but with a little bit of socket communication
overhead.

Regards,
-agentzh

agentzh

Hello!

On Wed, Oct 14, 2015 at 11:49 AM, Yichun Zhang (agentzh) wrote:
> Oh, we can have a more efficient approach using the socket pairs like below:
>
> 1. Each worker has only one such listening socket.
> 2. Each worker runs a background light thread created by
> ngx.timer.at() that continuously reads from the socket any new
> messages and then dispatch the messages to individual subscribers via
> the ngx.semaphore API.
> 3. Each subscriber thread waits on the semaphore.
> 4. The external service calls a publishing endpoint that writes to the
> correct worker process's listening socket.
> 5. The key should included in the messages for the dispatcher described in 2).
>

Forgot to mention that all these details can be encapsulated in a
standalone Lua library (in the same spirit of lua-resty-lock) so that
we don't have to reinvent the wheels everytime we need it ;)

Well, just my 2 cents.

Regards,
-agentzh

erik.l.nelson

Yichun Zhang (agentzh) wrote on Tuesday, October 13, 2015 11:50 PM
> On Wed, Oct 14, 2015 at 11:41 AM, Yichun Zhang (agentzh) wrote:
> > To think aloud, one possible solution is to use datagram (unix)
> > domain socket pairs. To make this concrete, the waiting request handler (or
> > the subscriber) does these:
> >
> 
> Oh, we can have a more efficient approach using the socket pairs like
> below:
> 
> 1. Each worker has only one such listening socket.
> 2. Each worker runs a background light thread created by
> ngx.timer.at() that continuously reads from the socket any new messages
> and then dispatch the messages to individual subscribers via the
> ngx.semaphore API.

Individual subscribers are individual light threads?

I'm not clear yet how the ngx.semaphore works, which makes it a little hard for me to reason about it.  Sorry if this is obvious or already covered.
   a.  semaphores work within a worker, or across all workers? 
   b.  does triggering a semaphore also pass some other information?
   b.  multiple light threads can wait on a semaphore?  When it's triggered, do they all run, or just one?

> 3. Each subscriber thread waits on the semaphore.
> 4. The external service calls a publishing endpoint that writes to the
> correct worker process's listening socket.

> 5. The key should included in the messages for the dispatcher described
> in 2).

The key is a per-light-thread key?  Do light threads have a unique id?  How does the ngx.timer.at() thread dispatch to a particular light thread?

> This can save a lot of sockets in case of large number of subscribers.
> No extra sleeping delays but with a little bit of socket communication
> overhead.

This method does save sockets, possibly at the cost of greater dispatch complexity?  Your first solution sounded like it was close to being a general-purpose inter-thread message passing library. :)

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

agentzh

Hello!

On Wed, Oct 14, 2015 at 10:14 PM, Nelson, Erik - 2 wrote:
> Individual subscribers are individual light threads?
>

Yes, typically across many different request handlers in the same
worker process.

> I'm not clear yet how the ngx.semaphore works, which makes it a little hard for me to reason about it.  Sorry if this is obvious or already covered.
>    a.  semaphores work within a worker, or across all workers?

It's per worker otherwise we don't need the sockets at all.

>    b.  does triggering a semaphore also pass some other information?

No, it's just affecting the control flow. The data can be passed from
the background thread to the subscriber thread easily since it's in
the same Lua VM. You could use lua-resty-lrucache for it, for example.
Just index the value via the key.

>    b.  multiple light threads can wait on a semaphore?  When it's triggered, do they all run, or just one?
>

It involves P/V operations. So when multiple light threads wait on a
single semaphore, it means multiple P operations while a single
"trigger" means a single V operation which makes just one subscriber
available. N P operations require a corresponding n V operations.
That's how semaphores are supposed to work. In your case, you need a
list of semaphores, one for each subscriber. Allocating a semaphore is
WAY cheaper than creating a socket pair.

>
> The key is a per-light-thread key?  Do light threads have a unique id?  How does the ngx.timer.at() thread dispatch to a particular light thread?
>

It's easy to generate a unique. Usually you just use the (global)
session ID if that's already readily available. Usually, using the
combination of the current worker PID, current time (milli)seconds,
and a monotonic counter number, should already be good enough. Also,
you could generate a GUID or UUID via an external library (which is
potentially more expensive though).

>
> This method does save sockets, possibly at the cost of greater dispatch complexity?  Your first solution sounded like it was close to being a general-purpose inter-thread message passing library. :)
>

Well, the 2nd approach can be much more efficient in case of MANY
concurrent requests. And the 2nd approach already offload the work to
all the nginx worker processes anyway and increasing the parallelism
further does no good but harm (keep in mind that nginx workers are
single-threaded per se and each individual CPU core should already be
bound to an nginx worker).

Regards,
-agentzh

erik.l.nelson

Yichun Zhang wrote on Wednesday, October 14, 2015 12:22 PM
> On Wed, Oct 14, 2015 at 10:14 PM, Nelson, Erik - 2 wrote:
> 
>>   b.  does triggering a semaphore also pass some other information?
> 
> No, it's just affecting the control flow. The data can be passed from
> the background thread to the subscriber thread easily since it's in the
> same Lua VM. You could use lua-resty-lrucache for it, for example.
> Just index the value via the key.
 
lua-resty-lrucache is recommended because of the potentially buggy optimizations you mentioned in the data sharing guidelines?

> 
>>    b.  multiple light threads can wait on a semaphore?  When
>>    it's triggered, do they all run, or just one?
>>
> 
> It involves P/V operations. So when multiple light threads wait on a
> single semaphore, it means multiple P operations while a single
> "trigger" means a single V operation which makes just one subscriber
> available. N P operations require a corresponding n V operations.
> That's how semaphores are supposed to work. 

Not important to my case, but are the light threads triggered in the same order in which they waited?

> 
> It's easy to generate a unique. Usually you just use the (global)
> session ID if that's already readily available. Usually, using the
> combination of the current worker PID, current time (milli)seconds, and
> a monotonic counter number, should already be good enough.

The monotonic counter number is shared between light threads in this case?

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

agentzh

Hello!

On Thu, Oct 15, 2015 at 11:06 PM, Nelson, Erik - 2 wrote:
>
> lua-resty-lrucache is recommended because of the potentially buggy optimizations you mentioned in the data sharing guidelines?
>

Any dictionary that is per-worker should work. Just need to be careful
about ever growing hash tables which can result in memory leaks.
lua-resty-lrucache has a size limit so it's guaranteed to be safe.

>
> Not important to my case, but are the light threads triggered in the same order in which they waited?
>

Maybe we could make it work that way. Not 100% sure at this point.
Then it's easier to pass data from publishers to subscribers (without
using a hash table but just a simple queue). Need to think more about
it.

>
> The monotonic counter number is shared between light threads in this case?
>

Yes, of course.

Regards,
-agentzh

erik.l.nelson

Yichun Zhang (agentzh) wrote on Tuesday, October 13, 2015 11:50 PM

>... and then dispatch the messages to individual subscribers via the
> ngx.semaphore API.

What's the timeline for ngx.semaphore?

Erik

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

agentzh

Hello!

On Fri, Oct 16, 2015 at 11:37 PM, Nelson, Erik - 2 wrote:
>
> What's the timeline for ngx.semaphore?
>

Before 1 December, 2015 if everything goes smoothly.

Regards,
-agentzh