Git Product home page Git Product logo

Comments (3)

MicahZoltu avatar MicahZoltu commented on September 21, 2024

I suspect this is OS dependent. The stub server binds to a particular address (usually 1337) and if the underlying OS doesn't release that binding when the process is killed then the subsequent run will fail due to port in use. It also depends on what exactly a ctrl+c does on the OS in question. In *nix it sends a SIGINT signal, which the stub server could catch, manually unbind the ports, then process exit. However, you can only have a single SIGINT handler in your entire node application and having that handler in a library would be very bad form. We could put the handler in the ethrpc test suite and then have that call server.destroy. This would require adding a sigint handler to every describe in ethrpc tests that use the stub server I believe. I believe the most correct place for this would be in Mocha, but it appears that they decided not to handle SIGINT because they couldn't guarantee it would run correctly (we would have the same problem if we tried to implement it ourselves).

If you wait a couple minutes (for timeouts) does the port eventually get opened up so it can be re-used?

I don't believe the effort required to fix this is worth the gains since this is a transient problem that occurs when you SIGINT tests in the middle of a run, and making the tests robust against this kind of interruption is fairly costly.

from ethereumjs-stub-rpc-server.

tinybike avatar tinybike commented on September 21, 2024

If you wait a couple minutes (for timeouts) does the port eventually get opened up so it can be re-used?

It does not. It's been a couple days now and the port never opens up again. Is it possible to pre-emptively unbind the ports before the tests are run, in case the tests don't exit cleanly?

from ethereumjs-stub-rpc-server.

MicahZoltu avatar MicahZoltu commented on September 21, 2024

No, I actually ran into this issue (port in use by killed process) for other reasons and apparently on Linux there is no to force the unbinding of a port and the OS never cleans up used ports.

Out of curiosity, if you ask the OS what is using port 1337, 1338, 2337, 2338 what does it say? I wonder if you have a process still running that actually has the port bound? The OS should have timed out the socket after a minute or two (assuming defaults and linux).

from ethereumjs-stub-rpc-server.

Related Issues (1)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.