Reaction on an error returned from trace_create()

[Dimitry Sibiryakov]

Hello All,

if call to trace_create() returns an error, it is written into server's
firebird.log but fbtracemgr's window stay empty which is puzzling.
Shouldn't the error text to be written into trace session instead of log?

--
WBR, SD.

[Alex Peshkoff]

The main problem with this is that plugin manager does not know format
of trace data sent to client by particular plugin (may be not text). May
be that error (not text but service error) should be raised to make it
reach client?

[Dimitry Sibiryakov]

Alex Peshkoff wrote 06.05.2024 17:29:
> The main problem with this is that plugin manager does not know format of trace
> data sent to client by particular plugin (may be not text). May be that error
> (not text but service error) should be raised to make it reach client?

But it sends strings like "Trace session ID 1 started/suspended/etc" and
buffer overflow messages in text so data flow is assumed to be text only.

--
WBR, SD.

[Vlad Khorsun]

06.05.2024 18:20, 'Dimitry Sibiryakov' via firebird-devel:

>   Hello All,
>
>   if call to trace_create() returns an error, it is written into server's firebird.log but fbtracemgr's window stay empty which is
> puzzling.

When trace_create() failed to create trace plugin there is nobody who can write
into trace log. Engine doesn't write into trace log by itself. Instead, if necessary,
trace factory could write error mesage using ITraceLogWriter object passed in with
ITraceInitInfo parameter.

>   Shouldn't the error text to be written into trace session instead of log?

See above.

Regards,
Vlad

[Vlad Khorsun]

06.05.2024 18:29, Alex Peshkoff:

> On 5/6/24 18:20, 'Dimitry Sibiryakov' via firebird-devel wrote:
>> Hello All,
>>
>>   if call to trace_create() returns an error, it is written into server's firebird.log but fbtracemgr's window stay empty which is
>> puzzling.
>>   Shouldn't the error text to be written into trace session instead of log?
>>
>
> The main problem with this is that plugin manager does not know format of trace data sent to client by particular plugin (may be not
> text).

Plugin Manager manage plugins and did nothing else. It have no idea about interfaces (trace,
for ex.) implemented by plugins. And this is how it should be.

> May be that error (not text but service error) should be raised to make it reach client?

Client of trace service is unknown at this point. Instance of trace service have no relation
with instance of user attachment (or another service) that going to be traced (and failed to
create trace plugin). Such client could be even in different process (for CS).

Regards,
Vlad

[Alex Peshkoff]

On 5/6/24 19:37, Vlad Khorsun wrote:
> 06.05.2024 18:29, Alex Peshkoff:
>> On 5/6/24 18:20, 'Dimitry Sibiryakov' via firebird-devel wrote:
>>> Hello All,
>>>
>>>   if call to trace_create() returns an error, it is written into
>>> server's firebird.log but fbtracemgr's window stay empty which is
>>> puzzling.
>>>   Shouldn't the error text to be written into trace session instead
>>> of log?
>>>
>>
>> The main problem with this is that plugin manager does not know
>> format of trace data sent to client by particular plugin (may be not
>> text).
>
>   Plugin Manager manage plugins and did nothing else. It have no idea
> about interfaces (trace,
> for ex.) implemented by plugins. And this is how it should be.

Sorry - mistyped, certainly it's trace manager which detects such error.

>
> > May be that error (not text but service error) should be raised to
> make it reach client?
>
>   Client of trace service is unknown at this point. Instance of trace
> service have no relation
> with instance of user attachment (or another service) that going to be
> traced (and failed to
> create trace plugin). Such client could be even in different process
> (for CS).
>

Agree, directly raising an error is not a way to go here. But looks like
it may be returned using trace session.

[Vlad Khorsun]

06.05.2024 19:47, Alex Peshkoff:

>> > May be that error (not text but service error) should be raised to make it reach client?
>>
>>   Client of trace service is unknown at this point. Instance of trace service have no relation
>> with instance of user attachment (or another service) that going to be traced (and failed to
>> create trace plugin). Such client could be even in different process (for CS).
>>
>
> Agree, directly raising an error is not a way to go here. But looks like it may be returned using trace session.

With Firebird trace plugin it is written into trace log by trace factory.
See TraceFactoryImpl::trace_create() in src\utilities\ntrace\traceplugin.cpp

Regards,
Vlad

[Alex Peshkoff]

Yes, that's enough.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 06.05.2024 18:47:
>>   Client of trace service is unknown at this point. Instance of trace service
>> have no relation
>> with instance of user attachment (or another service) that going to be traced
>> (and failed to
>> create trace plugin). Such client could be even in different process (for CS).
>>
>
> Agree, directly raising an error is not a way to go here. But looks like it may
> be returned using trace session.

Create a plugin in the point where you have no way to report errors that may
happen to user who requested the operation... Strange design.

--
WBR, SD.

[Dimitry Sibiryakov]

Vlad Khorsun wrote 06.05.2024 18:52:
>> Agree, directly raising an error is not a way to go here. But looks like it
>> may be returned using trace session.
>
>   With Firebird trace plugin it is written into trace log by trace factory.
> See TraceFactoryImpl::trace_create() in src\utilities\ntrace\traceplugin.cpp

When a user application (fbtracemg) creates a trace session and TraceManager
fail to create an instance of trace plugin for it (because of an error in the
config the application used), I would expect that the error is delivered to the
application as a status, not just another text line in output and of course it
must not be written to a log on server which remote client cannot see and ignored.
If the manager can send a text line written into log by trace factory, it
must be able to send the status as well, right? Don't say a nonsense like "the
session is unknown here so function called here must send error text to the
session". Caller has the same possibilities as callee so if the factory can send
the line, the manager also can.
Current reaction on a plugin that uses status to report errors is like this:
firebird.log is polluted by endless error messages while remote user looks at
empty trace window guessing what's wrong. It is written nowhere that status
cannot be used to report errors. (Because what is its purpose here then?..)

--
WBR, SD.

[Vlad Khorsun]

07.05.2024 17:07, 'Dimitry Sibiryakov' via firebird-devel:

> Vlad Khorsun wrote 06.05.2024 18:52:
>>> Agree, directly raising an error is not a way to go here. But looks like it may be returned using trace session.
>>
>>    With Firebird trace plugin it is written into trace log by trace factory.
>> See TraceFactoryImpl::trace_create() in src\utilities\ntrace\traceplugin.cpp
>
>   When a user application (fbtracemg) creates a trace session and TraceManager fail to create an instance of trace plugin for it
> (because of an error in the config the application used), I would expect that the error is delivered to the application as a status,
> not just another text line in output and of course it must not be written to a log on server which remote client cannot see and
> ignored.

You may expect anything you like but first you must understand architecture and how parts
communicate with each other. I can explain it again but I'm not sure you want to hear anything
you not like. For the start - when trace session is created there is no TraceManager instance
that works with this new session. It will be created in another traced connection when some event
to trace happens. Even if you try to create TraceManager instance against new session immediately
- it gives you nothing, as trace config is parsed against traced database (service) and will not
produce any error when used with current service connection.

>   If the manager can send a text line written into log by trace factory, it must be able to send the status as well, right?

Such status will be received far not by the user who starts trace session.
And no - manager doesn't send anything into trace log. I already wrote about it.

> Don't
> say a nonsense like "the session is unknown here so function called here must send error text to the session".

It is a nonsense for those who understand nothing.

> Caller has the same
> possibilities as callee so if the factory can send the line, the manager also can.

Seems you not understand who is caller, who is callee and how they are interacts.

>   Current reaction on a plugin that uses status to report errors is like this: firebird.log is polluted by endless error messages
> while remote user looks at empty trace window guessing what's wrong. It is written nowhere that status cannot be used to report
> errors. (Because what is its purpose here then?..)

When trace factory set error in status, the engine have two possibilities:
- raise error in the context of traced connection, or
- log error and don't bother user with trace plugin problems.

Current implementation chooses second way.

Such exception can't be delivered to the trace session as native error. There is
no way to pass exception from one connection to another one. And, yes, both connections
could be handled by different processes.


Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 07.05.2024 16:56:
>   You may expect anything you like but first you must understand architecture
> and how parts
> communicate with each other. I can explain it again but I'm not sure you want to
> hear anything
> you not like. For the start - when trace session is created there is no
> TraceManager instance
> that works with this new session. It will be created in another traced
> connection when some event
> to trace happens.

It is obvious but this instance of TraceManager has at hand TraceInitInfoImpl
which includes ITraceLogWriter exactly to communicate with the instance that
does work with user session, right? It can use this writer to send "something"
to the trace session. Currently (by unfortunate design) this "something" is
limited to text but still it is better than nothing.

> Such status will be received far not by the user who starts trace session.
> And no - manager doesn't send anything into trace log. I already wrote about it.

You wrote this about PluginManager which is a different beast, no?

> Seems you not understand who is caller, who is callee and how they are interacts.

May be. English is not my strong side. I call TraceManager::update_session
"caller" and ITraceFactory::trace_create "callee" because former calls latter.
For interaction I guess it includes pushing of arguments into a stack and
transfer control flow.

> When trace factory set error in status, the engine have two possibilities:
> - raise error in the context of traced connection, or
> - log error and don't bother user with trace plugin problems.

Did you forgot third possibility "inform about the error trace session which
interact to user application"?

> Such exception can't be delivered to the trace session as native error. There is
> no way to pass exception from one connection to another one. And, yes, both connections
> could be handled by different processes.

Cannot status be serialized to some data buffer and sent to other connection
the same way as a text is?

--
WBR, SD.

[Vlad Khorsun]

07.05.2024 18:20, 'Dimitry Sibiryakov' via firebird-devel:

> Vlad Khorsun wrote 07.05.2024 16:56:
>>    You may expect anything you like but first you must understand architecture and how parts
>> communicate with each other. I can explain it again but I'm not sure you want to hear anything
>> you not like. For the start - when trace session is created there is no TraceManager instance
>> that works with this new session. It will be created in another traced connection when some event
>> to trace happens.
>
>   It is obvious but this instance of TraceManager has at hand TraceInitInfoImpl which includes ITraceLogWriter exactly to
> communicate with the instance that does work with user session, right?

No. Instances of TraceManager doesn't communicate with each other. Its purpose is to
maintain private list of sessions to trace in parent connection with a corresponding list
of trace plugin's and to call methods of trace plugin's when traced event happens.

> It can use this writer to send "something" to the trace
> session. Currently (by unfortunate design) this "something" is limited to text but still it is better than nothing.

You still far from understanding of design, despite of its "[un]fortunality"

>>   Such status will be received far not by the user who starts trace session.
>> And no - manager doesn't send anything into trace log. I already wrote about it.
>
>   You wrote this about PluginManager which is a different beast, no?

No. It all was about TraceManager.

>>   Seems you not understand who is caller, who is callee and how they are interacts.
>
>   May be. English is not my strong side. I call TraceManager::update_session "caller" and ITraceFactory::trace_create "callee"
> because former calls latter.
>   For interaction I guess it includes pushing of arguments into a stack and transfer control flow.

It is too hard to understand that

- Service that ask engine to create trace session and then reads the trace log and send its content to
the fbtracemgr application to show it on user console

is not directly related with

- any of other database (and service) connections that each contains own instance of TraceManager that call
trace plugin's that write something into trace log ?

When you run SELECT - do you want to get error happens in BEFORE INSERT trigger of another connection ?

>>   When trace factory set error in status, the engine have two possibilities:
>> - raise error in the context of traced connection, or
>> - log error and don't bother user with trace plugin problems.
>
>   Did you forgot third possibility "inform about the error trace session which interact to user application"?

No, I didn't forgot not-existing "possibility".

>>   Such exception can't be delivered to the trace session as native error. There is
>> no way to pass exception from one connection to another one. And, yes, both connections
>> could be handled by different processes.
>
>   Cannot status be serialized to some data buffer and sent to other connection the same way as a text is?

For what ? We can also flight to the Moon, but for what ?

Finally, what do you want ?

You need a way to show plugin init error to the user that started trace ?
It was already shown how to do it.

You want to break all and every user connection when you started trace session with wrong configuration ?
No, it is not allowed - by unfortunate designer.

Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 07.05.2024 18:40:
>
>   Finally, what do you want ?
>
>   You need a way to show plugin init error to the user that started trace ?
> It was already shown how to do it.

Not just "show error", I want user application to understand that this is an
error. For that it must receive this error from IService::start() or
IService::query() via IStatus parameter which is purposed exactly for this.
Parsing of text output is not an option.

--
WBR, SD.

[Vlad Khorsun]

07.05.2024 19:48, 'Dimitry Sibiryakov' via firebird-devel:

It is not error for service connection. It still can read trace log. And another
instances of trace plugin in another connections still can write something useful
into trace log of given trace session.

Vlad

[Dimitry Sibiryakov]

Vlad Khorsun wrote 07.05.2024 19:07:
>>    Not just "show error", I want user application to understand that this is
>> an error. For that it must receive this error from IService::start() or
>> IService::query() via IStatus parameter which is purposed exactly for this.
>> Parsing of text output is not an option.
>
>   It is not error for service connection. It still can read trace log. And another
> instances of trace plugin in another connections still can write something useful
> into trace log of given trace session.

May be. If they don't fail with exactly the same error. But where do you see
a problem? If other instances of the plugin write something useful it will be
delivered on the next call of IService::query(). Getting of an error doesn't
terminate trace session the same way as getting an error from SQL doesn't
terminate ordinary attachment. Why would it?..

--
WBR, SD.

[Vlad Khorsun]

07.05.2024 22:10, 'Dimitry Sibiryakov' via firebird-devel:

> Vlad Khorsun wrote 07.05.2024 19:07:
>>>    Not just "show error", I want user application to understand that this is an error. For that it must receive this error from
>>> IService::start() or IService::query() via IStatus parameter which is purposed exactly for this. Parsing of text output is not an
>>> option.
>>
>>    It is not error for service connection. It still can read trace log. And another
>> instances of trace plugin in another connections still can write something useful
>> into trace log of given trace session.
>
>   May be. If they don't fail with exactly the same error. But where do you see a problem?

I already explained a many details in this thread. Just read.

Vlad