Feature/add stop functionality

[Dustinhoefer]

After using disconnect, the background threads will still try to reconnect indefinitely. Also the listeners were never cleared.

[kohlerpop1]

@Dustinhoefer Can you explain more on After using disconnect, because I use it regularly and have never seen it attempt to reconnect indefinitely unless reconnecting is enabled, which is intended functionality. More details would be greatly appreciated.

[Dustinhoefer]

Yes, reconnecting is set to true, but at some point I simply want to completely stop reconnecting and free up all resources. Is there another way to do this?

Use Case: User enables TikTok Chat Monitoring today and disables it tomorrow

[kohlerpop1]

I do not think this was ever developed with that in mind to be honest.
To currently replicate this functionality, I would just set reconnect to false in the LiveClientSettings. Then once you no longer reference the LiveClient, it should be released and eventually garbage collected per normal JVM operations.

Idk if this is worth implementing into a library level. Our current thoughts were if the reconnect logic for a live client was to be done differently, we would just let them handle the reconnect logic themselves. This is currently what I do to manage my reconnects checking every 5+ mins roughly for my users. I would honestly recommend just doing that as it then becomes much easier to allocate/deallocate LiveClient instances and only keep the ones that you know are in use.

[Dustinhoefer]

Well, I would need to immediately know when someone goes live (thus the client with reconnect to true). But we also have users that have this functionality disabled (or disable it manually). Do you see a solution for this?

[kohlerpop1]

No library is capable of knowing immediately when someone goes live as it requires polling requests to TikTok. Checking too often will get your IP banned.

Regarding reconnecting though, I would simply have 2 different logic blocks.
One that manually handles reconnecting for those users that wish to enable it
And another that handles just connecting for users that do not have it enabled.

Then you can manually implement the reconnect logic to tune it to your amount of users while preventing your IP from sending too many requests.