Hello!
On Fri, Mar 02, 2018 at 08:47:17PM +0100, Valery Kholodkov wrote:
> On 02-03-18 17:06, Maxim Dounin wrote:
> >>> The question here is - why you want the file to be on disk, and
> >>> not just in a buffer? Because you expect the server to die in a
> >>> few seconds without flushing the fil
On 02-03-18 17:06, Maxim Dounin wrote:
The question here is - why you want the file to be on disk, and
not just in a buffer? Because you expect the server to die in a
few seconds without flushing the file to disk? How probable it
is, compared to the probability of the disk to die? A more
relia
Hello!
On Fri, Mar 02, 2018 at 09:54:31AM -0500, peanky wrote:
> > Bacause nginx smtp proxy is designed to protect / balance your own
> > smtp backends. If you want to proxy to external smtp servers,
> > consider using other solutions.
>
> Thank you for answer!
> 1. what is the diff between "m
Hello!
On Fri, Mar 02, 2018 at 10:12:02AM +0100, Nagy, Attila wrote:
> On 02/28/2018 03:08 PM, Maxim Dounin wrote:
> > The question here is - why you want the file to be on disk, and
> > not just in a buffer? Because you expect the server to die in a
> > few seconds without flushing the file to
On Fri, Mar 02, 2018 at 05:30:00AM -0500, sonpg wrote:
Hi there,
> my design is : enduser --> nginx --> sites (sharepoint site:443, web:80;
> 443)
> if server listen in 80 will redirect to 443
That seems generally sensible.
> i try to use stream block but it can't use same port.
Ah: you have
> Bacause nginx smtp proxy is designed to protect / balance your own
> smtp backends. If you want to proxy to external smtp servers,
> consider using other solutions.
Thank you for answer!
1. what is the diff between "my smtp" and "3rd party smtp" from technical
point of view?
2. which other sol
On 02/03/2018 14:17, Vladimir Homutov wrote:
Perhaps I should have expressed it as I'd like other people to sort by
date and that isn't going to happen unless it's easy, ie, built in.
autoindex on | off | date | text | ... ;
Well, if you want some interactive sorting, you have to do it in
j
On Fri, Mar 02, 2018 at 02:03:36PM +, James wrote:
> On 02/03/2018 11:33, Luciano Mannucci wrote:
>
> >> I'd like the option of order by date, "ls -t", "ls -rt". This helps
> >> because the text order of numbers is "10 11 8 9", see:
> >>
> >> http://nginx.org/download/
> > Well, this is way le
On 02/03/2018 11:33, Luciano Mannucci wrote:
I'd like the option of order by date, "ls -t", "ls -rt". This helps
because the text order of numbers is "10 11 8 9", see:
http://nginx.org/download/
Well, this is way less trivial than simply add a flag to reverse sort
order. It belongs indeed to
On Fri, 2 Mar 2018 10:33:45 +
James wrote:
> I'd like the option of order by date, "ls -t", "ls -rt". This helps
> because the text order of numbers is "10 11 8 9", see:
>
> http://nginx.org/download/
Well, this is way less trivial than simply add a flag to reverse sort
order. It belongs i
On 03/02/2018 11:42 AM, Aziz Rozyev wrote:
man page quote is related to the Valery’s argument that fsync wont affect
performance, forget it.
Of course it affects performance. But as for how much: it depends on
many factors. It's possible to build servers where the overall effect
will be neglig
Atilla,
man page quote is related to the Valery’s argument that fsync wont affect
performance, forget it.
It’s nonsense because you’re trying to solve the reliability problem at the
different level,
it has been multiple times suggested here already by maxim and Paul, that it’s
better
to inves
On 01/03/2018 11:54, Luciano Mannucci wrote:
It is probably trivial to add an option
to the configuration, something like "autoindex_reverse_sort" (set to
off by default), though I don'nt know if it would be usefull for other
nginx users...
I'd like the option of order by date, "ls -t", "ls -r
my design is : enduser --> nginx --> sites (sharepoint site:443, web:80;
443)
if server listen in 80 will redirect to 443
i try to use stream block but it can't use same port.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,278737,278885#msg-278885
On 02/28/2018 10:41 PM, Aziz Rozyev wrote:
Without fsyncing file's data and metadata a client will receive a positive
reply before data has reached the storage, thus leaving non-zero probability
that states of two systems involved into a web transaction end up inconsistent.
I understand why o
On 02/28/2018 03:08 PM, Maxim Dounin wrote:
The question here is - why you want the file to be on disk, and
not just in a buffer? Because you expect the server to die in a
few seconds without flushing the file to disk? How probable it
is, compared to the probability of the disk to die? A more
On 02/28/2018 11:33 PM, Peter Booth wrote:
This discussion is interesting, educational, and thought provoking.
Web architects
only learn “the right way” by first doing things “the wrong way” and
seeing what happens.
Attila and Valery asked questions that sound logical, and I think
there's valu
On 02/28/2018 11:04 AM, Aziz Rozyev wrote:
While it’s not clear why one may need to flush the data on each http operation,
I can imagine to what performance degradation that may lead of.
I store data on HTTP servers in a distributed manner and have a catalog
of where each file is. If I get back
18 matches
Mail list logo
