Re: [naviserver-devel] "connection already closed" vs "connection socket is detached" and the "rejectalreadyclosedconn" parameter

[Brian F. <bri...@ai...>]

Hi Gustaf

thanks for the explanation and the commit. I got confused because the discussion on https://openacs.org/forums/message-view?message_id=5659253 was about "connection socket is detached", when as you say that distinction came later.

This kind of parameter is handy with clients running older versions of our application where it's not feasible to immediately upgrade them. With the parameter, we could theoretically reduce the noise in the error logs, while the client awaits an upgrade.

thanks as always
Brian
________________________________
From: Gustaf Neumann <ne...@wu...>
Sent: Saturday 30 September 2023 11:08 am
To: nav...@li... <nav...@li...>
Subject: Re: [naviserver-devel] "connection already closed" vs "connection socket is detached" and the "rejectalreadyclosedconn" parameter

Hi Brian,

The parameter "rejectalreadyclosedconn" does what it is supposed to do
(controls error messages, when someone tries to write to a connection,
which was already closed). The parameter was introduced at a time,
before the distinction between closed and detached connections was
introduced in the code. So, I read your request to extend the meaning of
the parameter to cover detached connections as well.

 > Have I misunderstood something or is this not possible?

There is no hard reason rendering this as impossible. One could either
introduce (a) another parameter "rejectalreadydetachedconn" or (b) make
"rejectalreadyclosedconn" slightly misleading from the name to cover as
well the detached cases.

Since the parameter is just for legacy applications, which did not care
about the semantics, when someone tries to write to a connection which
is not available anymore (leading to potentially complex debugging
questions), the updated code [1] follows the (b) approach. I see the
potential misuse of the parameter to encourage lazy coding practices,
but i do understand as well code-maintainers who see large amounts of
errors in their log files on busy sites, not having the resources right
now to address these...

-gn

[1]
https://bitbucket.org/naviserver/naviserver/commits/725cf9475fe78f495918ed4549bf434cf2daaf96





_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel