ON DISCONNECT triggers are not executed during forced attachment shutdown

[ilya071294]

There are 4 cases of forced attachment shutdown:

1. During server shutdown.
2. During database shutdown (gfix -shut full -force 0).
3. It's deleted from MON$ATTACHMENTS by another attachment.
4. (FB4+) It's closed after idle timeout.

Currently ON DISCONNECT triggers are not executed in all of these cases. The first case is OK but in other cases it makes sense to execute triggers.

[ilya071294]

I will prepare a PR.

[asfernandes]

What if a ON DISCONNECT triggers enters in loop and never ends?

Will a second attempt to shutdown or delete the attachment will make it not run again?

[AlexPeshkoff]

On 11/10/21 3:36 PM, Adriano dos Santos Fernandes wrote: What if a ON DISCONNECT triggers enters in loop and never ends? Will a second attempt to shutdown or delete the attachment will make it not run again?

In FB4+ best solution is timeout.

[ilya071294]

What if a ON DISCONNECT triggers enters in loop and never ends?

If we talk about the current situation in FB3, is there any way to shutdown an attachment which cannot get out of an endless loop in ON DISCONNECT trigger? I mean when the attachment is closed normally by itself.

[AlexPeshkoff]

On 11/10/21 5:14 PM, Ilya Eremin wrote: What if a ON DISCONNECT triggers enters in loop and never ends? If we talk about the current situation in FB3, is there any way to shutdown an attachment which cannot get out of an endless loop in ON DISCONNECT trigger? I mean when the attachment is closed normally by itself.

Do not forget that trigger behavior may be different. It may ebter such loop pr may not dependng upon 100500 reasons. BTW, I'm unsure is it worth changing ON DISCONNECT triggers in FB3.

[hvlad]

What if a ON DISCONNECT triggers enters in loop and never ends?
Will a second attempt to shutdown or delete the attachment will make it not run again?

In FB4+ best solution is timeout.

What kind of timeout do you mean here ?
Nor connection not statement timeouts is not active by default.

[hvlad]

BTW, I'm unsure is it worth changing ON DISCONNECT triggers in FB3.

Of course.

[AlexPeshkoff]

On 11/10/21 6:02 PM, Vlad Khorsun wrote: What if a ON DISCONNECT triggers enters in loop and never ends? Will a second attempt to shutdown or delete the attachment will make it not run again? In FB4+ best solution is timeout. What kind of timeout do you mean here ? Nor connection not statement timeouts is not active by default.

But can we activate one internally before running that triggers? I suppose yes.

[hvlad]

Yes, we can. With what value ?

[AlexPeshkoff]

Looks like we want to run ON DISCONNECT triggers when database shutdown and when attachment is deleted from MON$ATTACHMENTS. What should be done in a case when that triggers runs too long? Can use of timeouts help?

[ilya071294]

What should be done in a case when that triggers runs too long? Can use of timeouts help?

I don't like the solution with timeouts because in general case we don't know how long a trigger runs. Maybe it's better to have an ability to manually kill attachments which are hanging in ON DISCONNECT triggers.

[AlexPeshkoff]

On 11/11/21 11:35 AM, Ilya Eremin wrote: What should be done in a case when that triggers runs too long? Can use of timeouts help? I don't like the solution with timeouts because in general case we don't know how long a trigger runs. Maybe it's better to have an ability to manually kill attachments which are hanging in ON DISCONNECT triggers.

If such trigger really hangs that (for 1% of users) will mean 'can not disconnect attachments for unknown reason' and (for 99% of users) - 'something hanged'. I doubt any one of them will use mentioned special ability. On the other hand currently ON DISCONNECT triggers do not run at all in such a case, i.e. if they will be termuinated by timeout and therefore rolled back that will be at least backward compatible.

[aafemt]

But timeout will create a weird situation "sometimes it works and sometimes don't and there is no way to find out why".

[romansimakov]

Do we really need to think about it? Any routing can be written in such a way. чт, 11 нояб. 2021 г. в 14:15, Dimitry Sibiryakov ***@***.***>:

…

But timeout will create a weird situation "sometimes it works and sometimes don't and there is no way to find out why". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7042 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMMXKSKFTM3GUKIQU53HTTULOQT5ANCNFSM5HXZBG5A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Roman Simakov

[aafemt]

Do we really need to think about it?

If we are going to do support job without headache - yes. I personally see nothing wrong with connection's instant death as if on SIGTERM.

[aafemt]

If the server is shut down by critical UPS state (or even simple Windows shutdown) Firebird has to stop ASAP. We cannot let unpredictable user code to interfere and risk that OS just terminate Firebird processes with unwritten cache etc.

[AlexPeshkoff]

On 11/11/21 2:38 PM, Dimitry Sibiryakov wrote: If the server is shut down by critical UPS state (or even simple Windows shutdown) Firebird has to stop ASAP. We cannot let unpredictable user code to interfere and risk that OS just terminate Firebird processes with unwritten cache etc.

Exactly. Therefore I've always argued that during server shutdown ON DISCONNECT triggers should not run at all. But how is it related with DB shutdown or attacment termination when it's record deleted from mon$attachments?

[aafemt]

But how is it related with DB shutdown or attacment termination when it's record deleted from mon$attachments?

No practical difference between them. Admin shutting DB down or terminating connection may be a little more patient but still situation when these operations are silently not finished in timely fashion or lead to "did something but forgot the rest" are hard to diagnose. Unless you are going to do it in the way that session deleting from mon$attachments or shutting down DB will get message "ON DISCONNECT triggers A,B and C in attachments xxx,yyy and zzz failed to finish in time and were aborted". Do you?..

[AlexPeshkoff]

I think that such warning(s) must be present in mentioned cases.

[pavel-zotov]

=== QA notes ===
Test not needed for this ticket: issues are covered by following tests in functional/trigger/database/ :

test_disconnect_02.py // ON DISCONNECT trigger must fire during database shutdown (gfix -shut full -force 0)
test_disconnect_03.py // ON DISCONNECT trigger must fire if attachment is deleted from MON$ATTACHMENTS by another attachment
test_disconnect_04.py // ON DISCONNECT trigger must fire if attachment is closed by IDLE timeout.
test_disconnect_05.py // ON DISCONNECT trigger and OnDisconnectTriggerTimeout expiration

NB. For unknown reason test_disconnect_05.py fails all runs on Linux (but passes fine on Windows).