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.