InvokeRepeating stops executing after long periods of time

I built a master server that runs as a Unity “game”. Because its a master server for multiplayer networking, it runs for long periods of time without restarting. After days to weeks of it being up without restarting, it appears that InvokeRepeating just stops executing the function. This is causing things to just randomly stop working and require it to reboot to fix it. Any thoughts on what could be going wrong?

Do not know for sure, and never been in your situation.

Thoughts that come to mind:

  1. most online games I know do reboot regularly :slight_smile:
  2. you could track time on your own , and maybe use a coroutine + your own time to determine when to run your method(s).

It’s a master server, so when it reboots all servers have to go offline. I’d prefer not to have to do that on a regular basis, plus the fact that things just randomly stop working.

I’ll try out coroutines or just using an Update method at some point if there’s no solution for InvokeRepeating. It’s just very strange that it appears to randomly stop working.

Ya, as I said – I’ve never been in that situation. Hope you get it resolved. :slight_smile:

Probably an issue with using 32-bit floats for timers; same thing would happen if you use Time.time. That’s something Unity would have to fix internally, so the only real workaround is to create your own InvokeRepeating replacement (and don’t use 32-bit floats, or at least not an ever-increasing number that’s a 32-bit float).

–Eric

Do you think coroutines would have the same issue?

No, or rather it depends on how you use them.

–Eric

Perhaps as a workaround, you could call CancelInvoke after a while and restart the Invoke.

It would be a while true loop most likely, that does a yield wait for seconds every iteration.

When I answered with using your own track of time and a coroutine, that’s what i was thinking…using your own time to determine the yield instruction/time.

If you have a number that’s reset to 0 frequently, and does not continue to increase indefinitely and thus run into 32-bit float precision limitations sooner or later (e.g. Time.time), then you’re fine. Or a 64-bit float, which technically would eventually have the same problem, but would take far longer.

–Eric

Would yield WaitForSeconds have this problem? Or do I need to track the time myself and use yield return null?