LongPollingBot ease of deployment in multiple nodes

[jordillachmrf]

When deploying the application/bot to multiple K8s pods I got the following error

Error getting updates: [409] Conflict: terminated by other getUpdates request; make sure that only one bot instance is running org.telegram.telegrambots.meta.exceptions.TelegramApiRequestException: Error getting updates: [409] Conflict: terminated by other getUpdates request; make sure that only one bot instance is running

I need more than one instance/pod in order to have HA. but I can understand the limitation. With the current code it's not possible, as far as I know, to prevent this error, right ?

If that's the case I could create a PR that would allow the TelegramBot to tell DefaultBotSession's HandlerThread whether it's active or not. DefaultBotSession's HandlerThread will invoke callback.active() before invoking getUpdateList() method and thus we could have multiple pods with the LongPollingBot being deployed with just one instance invoking getUpdateList().

By default the current implementation will return active=true always but I could create my own bot extending LongPollingBot and adding a custom leader election solution between pods to decide whether the current pod is active or not.... but that's out of the scope of this PR.

Should I create the PR? Any other approach ?

[Chase22]

If you are already working on a kubernetes cluster i'd recommend looking into webhooks and then use a standard load balancing. Which i think is the simplest approach. If you need to use longpolling you can easily use the start() and stop() method of BotSession to implement something like that withouth requiring invasive changes to the library.

Basic Reasoning for that: If you'd implement such a feature for the vast majority of people this would be dead code. It introduces complexity into the library that is only needed in very few cases and since there is a way to implement this with the existing library i'd opt for not increasing the complexity. But @rubenlagus has the last say on this.

[jordillachmrf]

Actually the change is just a new method in the signature of longpolling bot, something like

protected boolean isActive() return true

Which will be invoked to decide whether the getUpdate has to be invoked.

Not a big change IMO

El dv., 17 de des. 2021, 20:22, Chase @.***> va escriure:

I think this is a very complex use case. In general if you are already working on a kubernetes cluster i'd recommend looking into webhooks and then use a standard load balancing. Which i think is the simplest approach. If you need to use longpolling you can easily use the start() and stop() method of BotSession https://github.com/rubenlagus/TelegramBots/blob/4882040822d202e146471d6196e3a40babbdb51a/telegrambots-meta/src/main/java/org/telegram/telegrambots/meta/generics/BotSession.java to implement something like that withouth requiring invasive changes to the library.

Basic Reasoning for that: If you'd implement such a feature for the vast majority of people this would be dead code. It introduces complexity into the library that is only needed in very few cases and since there is a way to implement this with the existing library i'd opt for not increasing the complexity. But @rubenlagus https://github.com/rubenlagus has the last say on this.

— Reply to this email directly, view it on GitHub https://github.com/rubenlagus/TelegramBots/issues/1014#issuecomment-996978072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6NNT26EK5PHNYQWXL4OE3UROEWBANCNFSM5KJB4JVQ . 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.

You are receiving this because you authored the thread.Message ID: @.***>