You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge torrust#1356: Fix bug: number of downloads for a torrent is reset
06ef1d5 fix: [torrust#1264] number of downloads preset when torrent is persisted (Jose Celano)
8f67f12 fix: [torrust#1264] partially. The correct number of downloads is persited (Jose Celano)
6beec3a refactor: [torrust#1264] add a database method to increase the number of downloads for a torrent (Jose Celano)
8a4dba3 refactor: [torrust#1264] rename variables (Jose Celano)
2fb1c6f reafactor: [torrust#1264] add a DB methog to get the number of completed downloads for one torrent (Jose Celano)
c5db71a refactor: [torrust#1264] remove unnecessary fn call (Jose Celano)
820329b refactor: [torrust#1264] return wether swarm stats have change or not after upserting a peer (Jose Celano)
Pull request description:
### Problem
**The number of downloads for a torrent is not persisted correctly**.
Even when persistence is enabled, it does not work. There are two cases when the counter is reset:
- When you restart the tracker.
- When a torrent entry is removed from the torrents repository because the last peer was removed (peerless torrents). This only happens if "removing peerless torrents" is enabled in the configuration.
Check the [issue](torrust#1264) to know how to reproduce the bug.
### Solution
Every time a new torrent entry is added in the torrent repository we need to load stats (also called persistent torrent, which only includes number of downloads currently) from the database. If persistence for stats is enabled.
### Other considerations
**1. Unused code**
There is a method to load the counters for all torrents but it's not used in production code.
```rust
fn import_persistent(&self, persistent_torrents: &PersistentTorrents) {
for (info_hash, completed) in persistent_torrents {
if self.torrents.contains_key(info_hash) {
continue;
}
let entry = EntryMutexStd::new(
EntrySingle {
swarm: PeerList::default(),
downloaded: *completed,
}
.into(),
);
self.torrents.insert(*info_hash, entry);
}
}
```
I guess it was added to load the information from the database when the tracker is restarted. However that's not enough because torrents are removed from the repository when they do not have peers (peerless torrents). That would work only if removing peerless torrents is disabled.
**2. Better solution**
I think there is a better solution than the one this PR applies. This PR is a temporary patch to fix the bug asap.
I would differentiate to different counters:
1. number of downloads per torrent while it was active in the swarm (since the tracker was restarted)
2. historical number of downloads per torrent per web service (since the service was put into production)
The counter 1 is what we have before merging this PR. The counter is reset every time the torrent is removed from the swarm. We can keep like it's now before merging this PR. This counter is handled at the in-memory torrent repository.
The new counter (counter 2) would be handled by the announce handler. After processing the announce request if the number of downloads has increased the handler also increases the historical counter. This new value should be the one exposed in the API.
```json
{
"torrents": 379508,
"seeders": 150440,
"completed": 58992, <- this should be the historical
"leechers": 264865,
"tcp4_connections_handled": 15,
"tcp4_announces_handled": 15,
"tcp4_scrapes_handled": 0,
"tcp6_connections_handled": 0,
"tcp6_announces_handled": 0,
"tcp6_scrapes_handled": 0,
"udp_requests_aborted": 556458,
"udp_requests_banned": 24773536,
"udp_banned_ips_total": 29868,
"udp_avg_connect_processing_time_ns": 478212,
"udp_avg_announce_processing_time_ns": 8724637,
"udp_avg_scrape_processing_time_ns": 296950,
"udp4_requests": 298728340,
"udp4_connections_handled": 104369821,
"udp4_announces_handled": 158354656,
"udp4_scrapes_handled": 3664492,
"udp4_responses": 273954123,
"udp4_errors_handled": 7540716,
"udp6_requests": 0,
"udp6_connections_handled": 0,
"udp6_announces_handled": 0,
"udp6_scrapes_handled": 0,
"udp6_responses": 0,
"udp6_errors_handled": 0
}
```
This patches solves the problem but pre-loading the historical data every time the torrent is added to the repository.
ACKs for top commit:
josecelano:
ACK 06ef1d5
Tree-SHA512: 2d1ad14d26efa981d24b1264640b5e2deaca621092ec61638e85e21dc83f92ad53a4041cb97e4e798611f3bfed610c7794b68027e43a847751c8ec022abc6b19
0 commit comments