How long will opened port keep worker alive?

[Juraj M.]

I see the port situation has changed in Chrome 114:

https://developer.chrome.com/docs/extensions/mv3/service_workers/service-worker-lifecycle/#chrome-114

> Sending a message using long-lived messaging keeps the service worker alive. Previously, opening a port reset the timers, but sending a message would not. Opening a port no longer resets the timers.

Which explains why my service worker is closed in 30s (and not 5 min.) when I just call:

```

const port = chrome.runtime.connect({name: "dials_page"});

```

(without actually using the port)

So, I want to keep worker alive while my extension page is opened, I need to send it a message every <30s?

[Oliver Dunk]

Yeah, that should be sufficient. Each message counts as activity and will reset the 30-second idle timer.

As a note, please be mindful about doing this. As I'm sure you realise, if you can rely on the service worker waking up when needed, that's far better than using something like this to forcefully keep things alive :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1fa29a79-0e19-4ac5-b828-43b9f5d792e5n%40chromium.org.

[Juraj M.]

Thanks Oliver!

I have a special use-case where background script will hold screenshots (various number) which may exceed 10MB for the time that user selects some "destination" in the extension page. 

So I need it to stay alive with the in-memory data while the page is opened.

[wOxxOm]

>  if you can rely on the service worker waking up when needed, that's far better than using something like this to forcefully keep things alive :)

It's better only for rarely invoked simple extensions, i.e. it's not universal to put it midly and there are many cases where an ephemeral service worker is either entirely unusable or is the least effective solution due to the very large overhead to restart the worker frequently and save/restore a complex state. The inflexible nature of hard-coding the timeouts (instead of dynamically adjusting them e.g. depending on the memory usage cap) is thus a bad thing, generally, because the negative impact of even one affected extension getting into the process churn loop is disproportionally huge.