GitLab

fix(decision): cleanup request queues

Add a peer id to an active partner queue

Make sure when request queues are idle that they are removed

fix #112

Control provider workers with experiment flag

connmgr: give peers more weight when actively participating in a session

(fixes linter issues)

make the WantlistManager own the PeerHandler

remove IPFS_LOW_MEM flag support

* HasBlockBufferSize and provideKeysBufferSize no longer matter as we have an
  infinite in-memory buffer.
* provideWorkersMax now defaults to 6 so changing this to 16 actually _increases
  memory consumption.

And remove all locks.

feat(messagequeue): rebroadcast wantlist

timing on test was failure prone, corrected

Make sure rebroadcast timer doesn't get reset if it's nil

Provide a failsafe to losing wants on other end by rebroadcasting a wantlist every thirty seconds

fix #99, fix #65

reduce provide workers to 6

Reduce memory allocation

This reverts commit fc1278e6.

It appears that using a buffer here is no longer necessary after the
upstream fix https://github.com/gogo/protobuf/pull/504

15 will _never_ succeed

This'll back up the queue but take a large load off the DHT.

dep: switch back to upstream pubsub

In preparation for switching over to go modules entirely. We no longer need our
fork.

refactor(messagequeue): remove dead code

Remove code that should have been cleaned up in last message queue fix

fix: limit use of custom context type

fix: remove non-error log message

fix(messagequeue): Remove second run loop

Revert to the old go-routine architecture for the messagequeue, which I believe is still compatible
w/ wantlist w/o mutex

fix #92

This can happen even when everything is working correctly.

fixes https://github.com/ipfs/go-ipfs/issues/6046

add gomod support // tag v0.0.1.

License: MIT
Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>

Goprocess returns a _custom_ context type. Unfortunately, golang has a bunch of
magic type assertions to efficiently handle built-in context types but launches
a new goroutine when deriving a new context from a custom context type.
Otherwise, it has no way to wait on the custom context's channel.

This fix just ensures we only ever have one of goroutines per provide worker by
deriving a (normal) cancelable context up-front and then using that.

fix(prq): fix a bunch of goroutine leaks and deadlocks