Skip to content

/ webtorrent

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Destroy functionality broken when torrent running #589

Closed
niieani opened this issue Jan 27, 2016 · 4 comments
Closed

Destroy functionality broken when torrent running #589

niieani opened this issue Jan 27, 2016 · 4 comments
Labels
area/node bug

Comments

@niieani
Copy link
Contributor

@niieani niieani commented Jan 27, 2016

It seems that destroying the torrent doesn't stop the DHT events from being emitted, resulting in actions on a destroyed torrent and an error thrown.
Running torrent.destroy() on a running torrent may cause the following error:

  if (self.destroyed) throw new Error('torrent is destroyed')
                      ^

Error: torrent is destroyed
    at Torrent.addPeer (/app/node_modules/webtorrent/lib/torrent.js:453:29)
    at emitOne (events.js:77:13)
    at Discovery.emit (events.js:169:7)
    at DHT.onPeer (/app/node_modules/torrent-discovery/index.js:66:10)
    at emitThree (events.js:102:20)
    at DHT.emit (events.js:175:7)
    at emit (/app/node_modules/bittorrent-dht/client.js:316:12)
    at onreply (/app/node_modules/bittorrent-dht/client.js:322:27)
    at onreply (/app/node_modules/bittorrent-dht/client.js:532:12)
    at Object.afterQuery [as callback] (/app/node_modules/k-rpc/index.js:272:18)
    at Socket.onmessage (/app/node_modules/k-rpc-socket/index.js:101:11)
    at emitTwo (events.js:87:13)
    at Socket.emit (events.js:172:7)
    at UDP.onMessage (dgram.js:480:8)
feross added a commit to mafintosh/k-rpc-socket that referenced this issue Jan 28, 2016
@feross
No events after destroy()
Loading status checks…
cab8599 
It seems that it’s possible for ‘message’ events to arrive on the
socket even after socket.close() is called. I guess this is why we have
a ‘close’ event.

Still, I think we should suppress messages that arrive after destroy()
was called.

This surfaced in a webtorrent issue:
webtorrent/webtorrent#589
@feross feross mentioned this issue Jan 28, 2016
Merged
@feross

This comment has been minimized.

Sign in to view
Copy link
Member

@feross feross commented Jan 28, 2016

Thanks for the issue. I think I figured out the source of the error. It's the new version of bittorrent-dht. It was completely rewritten to be much faster, but there's going to be a few kinks like this until it gets some more usage ;)

PR sent upstream.
@feross

This comment has been minimized.

Sign in to view
Copy link
Member

@feross feross commented Jan 28, 2016

And just like that, it's fixed! Re-install webtorrent to get the fix.
@feross feross closed this Jan 28, 2016
@feross feross removed the blocked label Jan 28, 2016
@niieani

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@niieani niieani commented Jan 28, 2016

Awesome, thanks!
On Thu, 28 Jan 2016 at 04:01, Feross Aboukhadijeh notifications@github.com
wrote:

Closed #589 #589.

—
Reply to this email directly or view it on GitHub
#589 (comment).
@niieani niieani mentioned this issue Feb 16, 2016
Closed
@lock

This comment has been minimized.

Sign in to view
Copy link

@lock lock bot commented May 4, 2018

This thread has been automatically locked because it has not had recent activity. To discuss futher, please open a new issue.
@lock lock bot locked as resolved and limited conversation to collaborators May 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area/node bug
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@niieani @feross
You can’t perform that action at this time.