Welcome! Log In Create A New Profile

Advanced

Re: Serve from cache but fire request to upstream server to increment page view counter

Quintin Par
April 04, 2012 11:52PM
This seems to very risky.

One more question:

The whole reason why I’d use post action is to take the time off from doing
a SSI. i.e. serve a page from cache in light speed and then let post action
take its own sweet time to complete.

But from Jonathan’s response I infer that a post actions response code is
passed to the client. Which means the client is made to wait till the post
action is complete. Right? If yes, that defeats the purpose.

On Wed, Apr 4, 2012 at 5:57 PM, Jonathan Matthews
<contact@jpluscplusm.com>wrote:

> On 4 April 2012 13:17, Quintin Par <quintinpar@gmail.com> wrote:
> > Thanks Appa.
> >
> > Why would you say this is not reliable? Is there data or experience to
> > suggest? The semantic is awesome. Precisely what I’ve been looking for.
>
> I'd also be interested in discovering any unreliability of this
> mechanism, as I'm planning to use it for some real-time logging
> shortly.
>
> The weaknesses that I've discovered thus far, which I think should all
> be fixed -- or at least modified as indicated below -- are
>
> * The client connection is held open until the post_action call completes
> * The response code returned to the client is the post_action's response
> code
> * The access.log entry logged reflects the post_action's URI, response
> code and (possibly; I forget) content length
>
> All of these render it difficult to use post_action as its name
> implies - to be competed *after* the client request is completely
> dealt with.
>
> I hope that at some point in the future, we'll be able to use
> post_action in a way which is invisible to the client, and to the
> logs. Perhaps with a post_action directive flag, indicating that any
> calls to this specific post_action URI should stay out of the logs and
> the client's view.
>
> J
>
> > On Wed, Apr 4, 2012 at 1:39 PM, Antonio P.P. Almeida <appa@perusio.net>
> > wrote:
> >>
> >> There's the post_action directive. But AFAIK is not that reliable.
> >>
> >> I would use Lua with the "new" cosocket API and do an HTTP request.
> >>
> >> Here's an example of a library built around it that talks with a Redis
> >> backend: https://github.com/agentzh/lua-resty-redis
> >>
> >> As stated post_action is another option:
> >>
> >> http://wiki.nginx.org/HttpCoreModule#post_action
> >>
> >>
> >> --appa
> >>
> >> _______________________________________________
> >> nginx mailing list
> >> nginx@nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx
> >
> >
> >
> > _______________________________________________
> > nginx mailing list
> > nginx@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> --
> Jonathan Matthews
> London, Oxford, UK
> http://www.jpluscplusm.com/contact.html
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Serve from cache but fire request to upstream server to increment page view counter

Quintin Par April 03, 2012 02:46AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Quintin Par April 04, 2012 12:10AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Antonio P.P. Almeida April 04, 2012 04:10AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Quintin Par April 04, 2012 08:18AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Antonio P.P. Almeida April 04, 2012 08:22AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Jonathan Matthews April 04, 2012 08:28AM

Re: Serve from cache but fire request to upstream server to increment page view counter

Quintin Par April 04, 2012 11:52PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 300
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready