Skip to content
This repository was archived by the owner on Oct 30, 2018. It is now read-only.

Pending offer never reduce because of mirrors #485

Closed
littleskunk opened this issue Oct 8, 2016 · 6 comments
Closed

Pending offer never reduce because of mirrors #485

littleskunk opened this issue Oct 8, 2016 · 6 comments
Assignees
Labels

Comments

@littleskunk
Copy link
Collaborator

littleskunk commented Oct 8, 2016

Package Versions

Replace the values below using the output from npm list storj. Use npm list -g storj if installed globally.

root@farmer:~# storjshare --version
StorjShare: 7.0.0
Core:       4.0.0
Protocol:   0.9.0

Replace the values below using the output from node --version.

v4.6.0

Expected Behavior

Please describe the program's expected behavior. Include an example of your
usage code in the back ticks below if applicable.

Sooner or later the pending offer should be finished or timed out. Time to send new OFFER.

Actual Behavior

Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.

At the beginning everything is working fine. I get a few shards. Pending offer increase and decrease.
As soon as I hit connection limit my node will stop working. It will stay on max pending offer and send no new OFFER message.

Last OFFER send 22:22:16

{"level":"debug","message":"pending offers 7 is less than concurrency true: 8","timestamp":"2016-10-08T22:22:19.880Z"}
{"level":"info","message":"sending OFFER message to {\"userAgent\":\"4.0.0\",\"protocol\":\"0.9.0\",\"address\":\"server021.storj.dk\",\"port\":5001,\"nodeID\":\"a69d4f2e3e97e4f26ece3d437b2825c5d7fed9e6\",\"lastSeen\":1475965336861}","timestamp":"2016-10-08T22:22:16.861Z"}

8 pending offer for more than one hour?

{"level":"debug","message":"pending offers 8 is less than concurrency false: 8","timestamp":"2016-10-08T23:38:52.373Z"}

At the same time I hit the connection limit.

{"level":"warn","message":"connection limit reached, destroying socket","timestamp":"2016-10-08T21:48:32.246Z"}
[...]
{"level":"warn","message":"connection limit reached, destroying socket","timestamp":"2016-10-08T22:13:22.697Z"}

My node is running with a limit of 150 connections. If I set it down to 50 I can reproduce the issue very fast. My node will open 8 datachannel, transfer the shards, hit the connection limit and than nothing for the next few hours.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

  1. Start farming with loglevel debug, high concurrency and low connection limit.
  2. Wait until connection limit reached and grep the logfile.
@littleskunk
Copy link
Collaborator Author

I was farming this night with 12 concurrency and a connection limit of 50.
20 minutes farming than I hit the connection limit and the next 5 hours my node was running at max pending offers.

@littleskunk
Copy link
Collaborator Author

Increased limit to 500. This time I didn't hit the limit but at the end the same problem. I also noticed that my pending offers increase but no data channel. Even the sending OFFER is missing. -> Mirror can't be the reason

I will run some more tests to find the pattern :)

@littleskunk
Copy link
Collaborator Author

Found it. We added a new error {"level":"warn","message":"dropping invalid contract with no renter id","timestamp":"2016-10-09T09:47:17.966Z"} but we don't remove it from pending offer. Pull request will follow.

@littleskunk
Copy link
Collaborator Author

Reduced my connection limit to 50 and installed that fix. Now my node is stable. The offer count gets down to 0 and I can accept new contracts.

@littleskunk
Copy link
Collaborator Author

Workaround hotfix
CLI: npm install -g littleskunk/storjshare-cli#hotfix
GUI: Download and install hotfix binary https://github.com/Storj/storjshare-gui/releases/tag/v2.0.7

@161chihuahuas
Copy link
Contributor

nice! good find.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants