Re: Explaining internal errors

On Wed, 30 Jun 2010 17:05:46 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 06/29/2010 05:31 PM, Amos Jeffries wrote:
>
>>>> With both tags, don't forget the %icap:: / %http:: scoping so we can
>> have
>>>> multiple servers error on one request (particularly with icap
failover
>>>> possible when working with a dead http origin).
>
>>> These new log fields are for the master transaction as a whole, I
think,
>>> and so they should not use a protocol prefix. The logged error codes
may
>>> be specific to a protocol, but the logging code would not know that.
>
>
>> Logging knows. The AccessLogEntry is broken down into protocol
>> sub-structs
>> and the tag code indicates exactly where the data is sourced. This is
as
>> much as logging needs to know.
>>
>> Anyway, you seem to be intending to store a formatted field layout
inside
>> the one code. That wasn't clear earlier. As long as we can easily
>> distinguish which if the many servers a particular error came from.
>
> I do not understand the above because the proposed logformat codes,
> %err_code and %err_detail are not specific to any one protocol (just
> like the local time or the transaction response time code, for example).
> The logged values may be specific to a protocol, but the logformat code
> is not.
>
> I hope it will all become clear when I post the patch. Take1 is being
> tested in production now.

Okay; just to clarify what we are talking about here:
  %err_code - name of ERR_* page the user was shown (if transaction was
non-recoverable).

  %err_detail - series of N error codes which occurred processing the
transaction.

By the above, I mean that every protocol involved may produce it's own
error codes. I was worried that you only had one being logged (such as
errno).

Will wait to see what the patch is.

Amos
Received on Wed Jun 30 2010 - 23:18:02 MDT