Skip to content
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

fsc hanging - java.net.SocketException: Software caused connection abort #6688

Open
scabug opened this issue Nov 18, 2012 · 9 comments
Open

Comments

@scabug
Copy link

scabug commented Nov 18, 2012

Had lots of problems using the FSC inside an IDE.

Eventually I tried running FSC from the command line and it just hung without any console output.

I then ran it again with "-verbose" and I noticed this...

Starting CompileServer on port 63048
[Port number: 63048]
java.net.SocketException: Software caused connection abort: connect
[Connecting to compilation daemon at port 63048 failed; re-trying...]
[Port number: 63048]
..... keeps looping forever and ever and ever  ...

This error occurs on a corporate laptop AND this only happens when I'm not connected to the corporate network. Eg working at home offline it doesn't work, but in the office is fine.

I've only ever seen the exception 'Software caused connection abort' when local firewall have interfered with the comms.
I recalled seeing something historically about that exception being possibly caused by a firewall preventing a connect to a port on the external interface (i.e. not the 127.0.0.1) and I'm not sure but I recall that having the server side listening on 0.0.0.0 was implicated but I Can't find the reference.

The compile server listens on all interfaces (a bind to 0.0.0.0).

CompileSocket.scala connects to the public ip address so I thought I'd check out what happens if I made it connect to 127.0.0.1 instead.

I hacked the source of Socket.scala to make it connect to localhost and immediately the standalone fsc now starts without any issue.


So the server still starts on 0.0.0.0 but the client by default now connects to 127.0.0.1. This avoids the assumed firewall issue.

In Socket.scala of package scala.tools.nsc

Change ...

def localhost(port: Int) = apply(InetAddress.getLocalHost(), port)

to

def localhost(port: Int) = apply(InetAddress.getByAddress(Array[Byte](127,0,0,1)), port)

This causes the compile client to connect to the private "localhost" interface rather than the public interface of the machine.

Perhaps confusingly the call ..

InetAddress.getLocalHost()

returns the public interface of the "local machine" rather than the private "localhost" interface.

FYI In my code I use

InetAddress.getByAddress(bytes 127.0.0.1)

rather than ..

InetAddress.getByName("localhost")

because 127.0.0.1 is supported by all properly configured IP stacks but the name "localhost" relies on host name resolution being setup (eg hosts file/dns/nis etc).

You can see the tweak here ..
https://github.com/Johnlon/scala at this commit ..
https://github.com/Johnlon/scala/commit/ca4ae045e128f123708bb9fa94d40194000e68ca

I would submit a pull request for this except when I tried to use SARBUS or whatever its called to build the dist it failed because it was unable to allocate a big enough heap on my machine because the build is hard coded to use big heaps and also because the docs say I'd need to fill out a paper form and send it back saying that there were no intellectual property rights issues and I wanted to raise this asap as its caused a lot of time wasting..

@scabug
Copy link
Author

scabug commented Nov 18, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6688?orig=1
Reporter: John Lon (johnlon)
Affected Versions: 2.9.2

@scabug
Copy link
Author

scabug commented Nov 19, 2012

@paulp said:
Can you confirm that InetAddress.getByName(null) also works for you?

@scabug
Copy link
Author

scabug commented Nov 20, 2012

John Lon (johnlon) said:
I'll give it a try - I see the docs say getByName(null) ought to result in loopback.

I'll let you know.

Thanks

@scabug
Copy link
Author

scabug commented Nov 22, 2012

John Lon (johnlon) said:
getByName(null) appears to work.

A 2.9.* build with this feature would be really handy as I'm not the only one at my place with this issue and probably not the only one worldwide.

Is this likely?

Needs porting to later versions too I suppose.

@scabug
Copy link
Author

scabug commented Nov 22, 2012

@retronym said:
There will be a 2.9.3 build in a month or two; you can submit a PR to the 2.9.x branch for inclusion.

@scabug
Copy link
Author

scabug commented Nov 23, 2012

John Lon (johnlon) said:
Sorry what's a PR?
2.9.3 is fine.

@scabug
Copy link
Author

scabug commented Nov 23, 2012

@retronym said:
pull request

@scabug
Copy link
Author

scabug commented Nov 23, 2012

John Lon (johnlon) said:
PR done

@scabug
Copy link
Author

scabug commented Nov 23, 2012

John Lon (johnlon) said:
How does it get into 2.10 onwards?

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

No branches or pull requests

1 participant