Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Events dont get triggered after online -> shutdown -> online [DNET940] #862

Closed
firebird-automations opened this issue May 29, 2020 · 8 comments

Comments

@firebird-automations
Copy link

Submitted by: Lars Weber (l.weber)

The problem we are having is that already queued events are not received by the EventHandler after the database has been shutdown and brought back online.

The RemoveEventError handler does not throw an event that the application could react on and reregister the events.

The application is requiered to be restarted, as the database events are registered on application startup.

@firebird-automations
Copy link
Author

Commented by: @cincuranet

Can you share some code of what kind of shutdown is done on the database?

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Author

Commented by: Lars Weber (l.weber)

I am using ibExpert to shutdown the database and to bring it online.
Active transactions are forced and multi-user mode is selected.
0 sec wait time

@cincuranet
Copy link
Member

@lweberprb (hope I found the right person) That's interesting scenario. Because when you shutdown the database, the connection (socket) is not closed. But only after next operation the error is returned. Hence the application does not see any error right away. I need to think a bit about what would be the best approach to this.

@la-we
Copy link
Contributor

la-we commented Aug 4, 2022

You found the right person ;)
As a quick follow up: our current workaround is, that we basically implemented a event watchdog. It expects that a certain event is received on the client side every couple seconds and if it is not, it tries to restart and reregister the events. This is probably not a feasible solution for the provider, but it kept us going in the meantime.

@cincuranet
Copy link
Member

Yeah, watchdog-like handling is common approach people use when using events.

I was playing with similar approach. The idea was to wait for any response from server for limited time and if no response is received then ask again for events. Although it works, I don't like it, it feels like a hack.

I asked "core" people whether there's something in Firebird protocol that could be helpful. I'll post my findings.

@cincuranet
Copy link
Member

OK, looks like there's nothing on protocol level that would help this situation. And I'm not sure whether periodically re-asking for events is a good idea. Especially because it relies on timeout and that might be very difficult to tune for default "pit of success" story (not that current situation is "pit of success" :\ ).

@cincuranet
Copy link
Member

I'm closing it now. Some kind of watchdog/heartbeat/... is required from developer. But I'll reopen if there's some new light shed onto this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants