Hi, Upon further testing, it appears the problem exists even with proxy_cache'd files with "proxy_cache_lock on".

(Please consider this a serious bug, which I'm surprised hasn't been detected before; verified on recently released 1.7.2)

On Jun 24, 2014, at 8:58 PM, Paul Schlie <schlie@comcast.net> wrote:

> Again thank you. However ... (below)
>
> On Jun 24, 2014, at 8:30 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
>> Hello!
>>
>> On Tue, Jun 24, 2014 at 07:51:04PM -0400, Paul Schlie wrote:
>>
>>> Thank you; however it appears to have no effect on reverse proxy_store'd static files?
>>
>> Yes, it's part of the cache machinery. The proxy_store
>> functionality is dumb and just provides a way to store responses
>> received, nothing more.
>
> - There should be no difference between how reverse proxy'd files are accessed and first stored into corresponding temp_files (and below).
>
>>
>>> (Which seems odd, if it actually works for cached files; as both
>>> are first read into temp_files, being the root of the problem.)
>>
>> See above (and below).
>>
>>> Any idea on how to prevent multiple redundant streams and
>>> corresponding temp_files being created when reading/updating a
>>> reverse proxy'd static file from the backend?
>>
>> You may try to do so using limit_conn, and may be error_page and
>> limit_req to introduce some delay. But unlikely it will be a
>> good / maintainable / easy to write solution.
>
> - Please consider implementing by default that no more streams than may become necessary if a previously opened stream appears to have died (timed out), as otherwise only more bandwidth and thereby delay will most likely result to complete the request. Further as there should be no difference between how reverse proxy read-streams and corresponding temp_files are created, regardless of whether they may be subsequently stored as either symbolically-named static files, or hash-named cache files; this behavior should be common to both.
>
>>> (Out of curiosity, why would anyone ever want many multiple
>>> redundant streams/temp_files ever opened by default?)
>>
>> You never know if responses are going to be the same. The part
>> which knows (or, rather, tries to) is called "cache", and has
>> lots of directives to control it.
>
> - If they're not "the same" then the tcp protocol stack has failed, which is nothing to do with ngiinx.
> (unless a backend server is frequently dropping connections, it's counterproductive to open multiple redundant streams; as doing so by default will only likely result in higher-bandwidth and thereby slower response completion.)
>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>> _______________________________________________
>> 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

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