pmtiles-swarm 0.35.2 β†’ 0.35.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/CHANGELOG.md +37 -0
  2. package/package.json +2 -2
package/CHANGELOG.md CHANGED
@@ -7,6 +7,43 @@
7
7
  ### 🐞 Bug fixes
8
8
  - _...Add new stuff here..._
9
9
 
10
+ ## 0.35.4
11
+ ### ✨ Features and improvements
12
+
13
+ ### 🐞 Bug fixes
14
+ - **Requires pmtiles-torrent 0.7.2, which is what actually stops `libtorrent list timed out after
15
+ 60000ms`.** The console header sat at "connecting…" and clicking an archive never loaded its
16
+ details, on a node that was otherwise seeding, downloading and serving tiles perfectly well.
17
+ 0.35.1 and 0.35.3 both chased this β€” through the sidecar's request loop, then through a slow
18
+ disk β€” and neither reached it.
19
+
20
+ The cost was in the listing itself. Reading one torrent's state is a blocking round-trip to
21
+ libtorrent's session thread, and the sidecar did three per torrent, so twenty archives cost
22
+ sixty, each queued behind whatever that one thread was doing. Measured on a session holding
23
+ twenty torrents: 0.66ms idle against 1001ms with the session busy hashing. The slow disk is real
24
+ and is what makes the session thread slow β€” but a slow session thread only becomes a minute of
25
+ waiting when the call costs sixty round-trips. The sidecar now keeps a status cache fed by
26
+ asynchronous updates, and listing reads a dictionary.
27
+
28
+ `^0.7.1` already admits 0.7.2, so a fresh install picks the fix up on its own. The floor is
29
+ raised anyway, because a node installed from a lock file does not.
30
+
31
+ ## 0.35.3
32
+ ### ✨ Features and improvements
33
+
34
+ ### 🐞 Bug fixes
35
+ - **Requires pmtiles-torrent 0.7.1, which stops the sidecar segfaulting.** The alert pump 0.7.0
36
+ introduced queued libtorrent's alert objects for another thread to read. libtorrent frees an
37
+ alert on the next `pop_alerts()`, and the pump pops about twice a second while a reader waits up
38
+ to 500ms before looking β€” so the read was routinely of memory the session had reclaimed, which
39
+ is not an exception but the process going away. Seen here as `libtorrent sidecar killed by
40
+ SIGSEGV` every five minutes, on the resume-data timer: saving resume data posts a burst of
41
+ alerts across every archive at once, which is exactly the traffic that leaves one queued past
42
+ the pop after it.
43
+
44
+ `^0.7.0` already admits 0.7.1, so a fresh install of 0.35.2 picks the fix up on its own. The
45
+ floor is raised anyway, because a node installed from a lock file does not.
46
+
10
47
  ## 0.35.2
11
48
  ### ✨ Features and improvements
12
49
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "pmtiles-swarm",
3
- "version": "0.35.2",
3
+ "version": "0.35.4",
4
4
  "description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
5
5
  "type": "module",
6
6
  "main": "src/index.js",
@@ -46,7 +46,7 @@
46
46
  "maplibre-gl": "^6.2.0",
47
47
  "parse-torrent": "^11.0.24",
48
48
  "pmtiles": "^4.4.1",
49
- "pmtiles-torrent": "^0.7.0",
49
+ "pmtiles-torrent": "^0.7.2",
50
50
  "webtorrent": "^3.0.21"
51
51
  },
52
52
  "engines": {