High CPU due to request spam to /cometd/connect

I’ve noticed that the material skin page causes high CPU usage (>30% on my laptop) since 1.5.0

This is due to the code constantly spamming long-polling POSTs to /cometd/connect

Looking at the response payload, I’d assume that this is caused by the server responding with "advice":{"interval":0}

[
   {
      "channel":"/meta/connect",
      "clientId":"65f180ab",
      "successful":true,
      "timestamp":"Sun, 29 Mar 2020 09:40:41 GMT",
      "advice":{
         "interval":0
      }
   },
   {
      "id":"8",
      "data":[
         "prefset",
         "server",
         "playingAtPowerOff",
         "0"
      ],
      "channel":"/65f180ab/slim/playerprefs/00:04:20:1f:6f:7c",
      "ext":{
         "priority":""
      }
   },
   {
      "channel":"/65f180ab/slim/playerprefs/00:04:20:1f:6f:7c",
      "id":"8",
      "data":[
         "prefset",
         "server",
         "playingAtPowerOff",
         "1"
      ],
      "ext":{
         "priority":""
      }
   },
   {
      "channel":"/65f180ab/slim/playerprefs/00:04:20:1f:6f:7c",
      "data":[
         "prefset",
         "server",
         "playingAtPowerOff",
         ""
      ],
      "id":"8",
      "ext":{
         "priority":""
      }
   }
]

[CDrummond]

…if you do install the git version of Material, edit server.js and change line 263 from this.cometd.init({url: '/cometd', logLevel:'off'}); to this.cometd.init({url: '/cometd', logLevel:'debug'}); - then reload Material. This will enable libcometd’s debug, and might provide useful information.

[Hypfer]

It happened again.

While there’s nothing in the js console (even with the debug GET parameter), I did get a lot of output on the server-side after setting network.cometd to debug logging.

Restarting the server did resolve it again (for now)

[20-04-13 16:01:19.3978] Slim::Web::Cometd::handler (253) Client (re-)connected: a4e8a1aa
[20-04-13 16:01:19.3982] Slim::Web::Cometd::Manager::register_connection (53) register_connection: a4e8a1aa
[20-04-13 16:01:19.3985] Slim::Web::Cometd::handler (298) Sending long-poll response immediately
[20-04-13 16:01:19.3988] Slim::Web::Cometd::handler (305) Waiting 0 seconds on long-poll connection
[20-04-13 16:01:19.4024] Slim::Web::Cometd::Manager::remove_connection (61) remove_connection: a4e8a1aa

The interesting part seems to be Sending long-poll response immediately which doesn’t seem to appear anymore after the restart

[20-04-13 16:03:10.9053] Slim::Web::Cometd::handler (305) Waiting 60 seconds on long-poll connection

Instead we’re seeing this, which apparently happens when the cometd manager thinks that the client has pending events https://github.com/Logitech/slimserver/blob/6a8d6f13f0e791cb004dc5ac8db99f51bb93ef22/Slim/Web/Cometd.pm#L298

The pending event is (at least in this case) this one loop:

[
  {
    channel => "/a4e8a1aa/slim/playerprefs/00:04:20:1f:6f:7c",
    data => ["prefset", "server", "playingAtPowerOff", 1],
    ext => { priority => "" },
    id => 8,
  },
  {
    channel => "/a4e8a1aa/slim/playerprefs/00:04:20:1f:6f:7c",
    data => ["prefset", "server", "playingAtPowerOff", ""],
    ext => { priority => "" },
    id => 8,
  },
]

which gets spammed constantly. https://github.com/Logitech/slimserver/blob/24e364a1813614378f73529a09845f896de407ff/Slim/Player/Player.pm#L232 The player in question was playing a webradio stream before yesterday and has been idle ever since. After the LMS restart, the playlist for the player was restored to local media only.

Not entirely sure what’s happening here but I suppose it’s not an issue with the material skin after all.