)]}'
{
  "commit": "de5271312abc8e070beedaed665a179ff810133f",
  "tree": "5679644096aed2559958a955a49967c55e326a86",
  "parents": [
    "d49a6021da350266e07de7bb880715e1910f86c0"
  ],
  "author": {
    "name": "Robert Stupp",
    "email": "snazy@snazy.de",
    "time": "Tue Apr 02 20:20:48 2024 +0200"
  },
  "committer": {
    "name": "jansupol",
    "email": "15908245+jansupol@users.noreply.github.com",
    "time": "Thu Apr 04 10:14:55 2024 +0200"
  },
  "message": "Fix thread leak/invasion\n\nJersey/Jetty, at least in the 3.1 version line, creates one thread for each HTTP request. This behavior was introduced with #5372 and seems not present in the 2.x or 3.x versions of Jersey.\n\nFrom the javadoc of `java.util.Timer`:\n```\nImplementation note: All constructors start a timer thread.\n...\nAfter the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer\u0027s task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur.\n```\nIt is fair to assume that \"arbitrarily long\" may also mean _never_, in case GC never runs.\n\nThis change replaces the timer \u0026 thread per request with a `ScheduledExecutorService` instance per `JettyHttpContainer`.\n\nAlso changed the set-timeout mechanism to use `System.nanoTime()` instead of `System.currentTimeMillis()`, because the latter is prone to wall-clock drift and can result into wrong timeout values.\n\nFixes #5588\n\nSigned-off-by: Robert Stupp \u003csnazy@snazy.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e43816b7ceba563b00c1709354fa05e627b1a337",
      "old_mode": 33188,
      "old_path": "containers/jetty-http/src/main/java17/org/glassfish/jersey/jetty/JettyHttpContainer.java",
      "new_id": "6a3805f805b95c625ffbeb2f2190ab4481e4aa6c",
      "new_mode": 33188,
      "new_path": "containers/jetty-http/src/main/java17/org/glassfish/jersey/jetty/JettyHttpContainer.java"
    }
  ]
}