Open issuefiler opened 3 years ago
Most of incoming info-hashes don’t actually make it to ms.flush
(NewLeech
’s OnSuccess
). Why bother checking duplicate info-hashes with lots of expensive database calls(The query itself is cheap, but the client overhead is not negligible.), when most of them can’t make it to AddNewTorrent
and AddNewTorrent
also has the dup-checking logic that is more reliable? Is it to save bandwidth?
connect: dial: dial tcp4 ...:7746: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
doExHandshake: metadata too big or its size is less than or equal zero
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
doExHandshake: readExMessage: readMessage: readExactly rLengthB: EOF
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
connect: dial: dial tcp4 ...:...: i/o timeout
https://github.com/boramalper/magnetico/blob/9c2183b91b5b37560607d1ebf98cfd1b542cfc27/cmd/magneticod/main.go#L110-L118
What’s the point of having the
DoesTorrentExist
call there when it allows multiple torrents to beSink
ed before theAddNewTorrent
call? With that, I still need to callDoesTorrentExist
again inAddNewTorrent
, otherwise it’ll eventually crash on identical torrents that have been double-Sink
ed.You’re aware of this
https://github.com/boramalper/magnetico/blob/9c2183b91b5b37560607d1ebf98cfd1b542cfc27/pkg/persistence/sqlite3.go#L122-L157
Sink
ing of the same torrent with theDoesTorrentExist
call at theAddNewTorrent
removed, or letAddNewTorrent
solely do theDoesTorrentExist
check.DoesTorrentExist
calls are expensive, taking about 50 milliseconds.