when I run my server application on eclipse it doesn't work and the error is shown as following:
java.net.SocketException: Unrecognized Windows Sockets error: 0: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
at MyServer.main(MyServer.java:17)
Exception in thread "main" java.lang.NullPointerException
at MyServer.main(MyServer.java:26)
I think you forgot to initialize the port and you are trying to connect to port=0 that is invalid. I thing that your application receives port via command line. When you are running it from eclipse you forgot to provide it. Do it using the run/debug configuration.
It is just a theory. I do not see your code.
Related
After some time (Of idle or after some run launches) the proccess Eclipse.exe is using my specific wanted port.
It obvious that when Java program is running the proccess "javaw" is need to run and this process is using the port (In case of serversocket).
Why does suddenly Eclipse using my port?
So when I running my application I get the predictable exception:
java.net.BindException: Address already in use: JVM_Bind
at java.net.DualStackPlainSocketImpl.bind0(Native Method)
at java.net.DualStackPlainSocketImpl.socketBind(Unknown Source)
at java.net.AbstractPlainSocketImpl.bind(Unknown Source)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
But when I restart Eclipse it release the port
I can't think of a reason why Eclipse would use port 1617. (It is reserved for "Nimrod Inter-agent Communication".)
I suspect that what has happened is that you have used Eclipse to run your application or some unit tests ... within the Eclipse JVM ... and there is a live ServerSocket still hanging around from the tests.
Try restarting Eclipse.
It is also possible that you are using a dodgy plugin which is ignoring the rules on port reservation ... just like your application is doing.
I have a java server. This server is used with my android application, the application takes in sound (microphone) and streams it directly to the server and out from the computer server. However I have this error when I try to run the server.
Exception in thread "main" java.net.BindException: Address already in use: Cannot bind
at java.net.DualStackPlainDatagramSocketImpl.socketBind(Native Method)
at java.net.DualStackPlainDatagramSocketImpl.bind0(Unknown Source)
at java.net.AbstractPlainDatagramSocketImpl.bind(Unknown Source)
at java.net.DatagramSocket.bind(Unknown Source)
at java.net.DatagramSocket.<init>(Unknown Source)
at java.net.DatagramSocket.<init>(Unknown Source)
at java.net.DatagramSocket.<init>(Unknown Source)
at com.datagram.Server.main(Server.java:28)
I am trying to use this code.
I just installed a new version of Android Studio and am trying to create a project using the built in templates.
My environment is:
Windows 7, SP1, 64 bit
In a secure domain environment and I am a domain administrator on my machine.
Here is what I am seeing:
C:\Users\stuz\AndroidStudioProjects\test>gradlew compileDebug --stacktrace
Downloading file://C:/Users/stuz/.gradle/wrapper/dists/gradle-1.10-all.zip
Exception in thread "main" java.lang.RuntimeException: java.net.UnknownHostExcep
tion: C
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAcc
essManager.java:78)
at org.gradle.wrapper.Install.createDist(Install.java:47)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:48)
Caused by: java.net.UnknownHostException: C
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.ftp.impl.FtpClient.doConnect(Unknown Source)
at sun.net.ftp.impl.FtpClient.tryConnect(Unknown Source)
at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
at sun.net.ftp.impl.FtpClient.connect(Unknown Source)
at sun.net.www.protocol.ftp.FtpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(Unknown Sour
ce)
at org.gradle.wrapper.Download.downloadInternal(Download.java:59)
at org.gradle.wrapper.Download.download(Download.java:45)
at org.gradle.wrapper.Install$1.call(Install.java:60)
at org.gradle.wrapper.Install$1.call(Install.java:47)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAcc
essManager.java:65)
The problem is in your gradle/wrapper/gradle_wrapper.properties file. I'm not sure how it happened, but you have an improper URL in there for the downloadable distribution of Gradle. Change that line from this:
distributionUrl=file://C:/Users/stuz/.gradle/wrapper/dists/gradle-1.10-all.zip
to this:
distributionUrl=http\://services.gradle.org/distributions/gradle-1.10-all.zip
This solution worked for me...
Find the file gradlew.bat on your project directory, in that file change DEFAULT_JVM_OPTS variable as below:
set DEFAULT_JVM_OPTS=-Dhttp.proxyHost=YOUR_HOST -Dhttp.proxyPort=PORT -Dhttp.proxyUser=USERNAME -Dhttp.proxyPassword=PASSWORD -Dhttps.proxyHost=YOUR_HOST -Dhttps.proxyPort=PORT -Dhttps.proxyUser=USERNAME -Dhttps.proxyPassword=PASSWORD
then run gradlew clean build.
Check if you are on secure network - if that is the case than in your gradle/wrapper/gradle_wrapper.properties file
distributionUrl=https\://services.gradle.org/distributions/gradle-2.4-all.zip
this line have https in it which is refused by secure network.
I changed to unsecure network and it started working for me.
under you project folder go to : platforms/android/cordova/lib/builders/GradleBuilder.js
find distributionUrl and Remove https with http and replace "services" with "downloads".
distributionUrl=http\://downloads.gradle.org/distributions/gradle-2.4-all.zip
you need to use the windows style file URI to make it valid
Windows Reference for File URI
distributionUrl=file\:///C\:/Users/<your_path_separated_by_/_chars>/gradle-2.4-all.zip
After changing the distribution url to http://services.gradle.org/distributions/gradle-1.10-all.zip .
If you still get unknown host exception for services.gradle.org, try setting the HTTP / HTTPS proxy to your environmental variables . See the below post
https://stackoverflow.com/a/59045565/4468693
I am working with a relativly unknown API. (ScrumWorks Pro) I am using it to export data into a SQL database. My issue is that I have moved my eclipse project from one computer to another and it stopped working. It continues to run fine on the old computer but I am getting the following error
Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://XXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl. It failed with:
Got Server returned HTTP response code: 503 for URL: http://XXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl while opening stream from http://dxzbid01.zhi.com:8080/scrumworks-api/api2/scrumworks?wsdl.
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
at javax.xml.ws.Service.<init>(Unknown Source)
at javax.xml.ws.Service.create(Unknown Source)
at com.danube.scrumworks.api2.ScrumWorksService.getConnection(ScrumWorksService.java:53)
at main.connectAPI(main.java:69)
at main.main(main.java:12)
Caused by: java.io.IOException: Got Server returned HTTP response code: 503 for URL: http://XXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl while opening stream from http://XXXXXXXXXXXXX.com:8080/scrumworks-api/api2/scrumworks?wsdl
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(Unknown Source)
... 11 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://XXXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
... 13 more
It looks like while it's running its failing to connect to the host. But it works completely fine with the exact same credentials on the other computer.
The magic words: Server returned HTTP response code: 503. The answer will be in your server logs.
From https://www.rfc-editor.org/rfc/rfc2616#section-10.5.4:
The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server.
make sure that url
http://XXXXXXXXXX:8080/scrumworks-api/api2/scrumworks?wsdl
is accessible, if not able to access the 8080 port, check your firewall settings in that machine (allow that 8080 port to accessible)
The problem was that the newer computer had a newer version of Java installed which broke parts of the API.
I'm running a 3rd party app which fails with the following stacktrace when trying to create a SSL connection to a server:
The root exception is this:
Caused by: java.lang.SecurityException: Toolkit not encapsulated by a jar.
at com.rsa.jcm.f.hq.a(Unknown Source)
at com.rsa.jcm.f.jg.b(Unknown Source)
at com.rsa.crypto.jcm.ModuleLoader.a(Unknown Source)
at com.rsa.crypto.jcm.ModuleLoader.load(Unknown Source)
... 43 more
Has anyone seen this occur when connecting over SSL that uses RSA? I've worked the google and there isn't anything obvious as to why this would happen.
This particular error happens on a Mac, and I've got a windows version of the same app which works correctly. Main difference being they bundle the JRE in the windows version, so I checked various security policies etc but there are no great differences in the JRE on windows vs the JRE on my mac.
The full stacktrace looks like this:
Caused by: java.lang.Error: Problem loading module.
at com.rsa.cryptoj.o.ju.g(Unknown Source)
at com.rsa.cryptoj.o.ju.c(Unknown Source)
at com.rsa.cryptoj.o.gd.a(Unknown Source)
at com.rsa.cryptoj.o.dm.b(Unknown Source)
at com.rsa.cryptoj.o.dm.<clinit>(Unknown Source)
at com.rsa.cryptoj.o.me.newInstance(Unknown Source)
at javax.crypto.Cipher.chooseProvider(Cipher.java:845)
at javax.crypto.Cipher.init(Cipher.java:1348)
at sun.security.ssl.CipherBox.<init>(CipherBox.java:175)
at sun.security.ssl.CipherBox.newCipherBox(CipherBox.java:208)
at sun.security.ssl.CipherSuite$BulkCipher.newCipher(CipherSuite.java:467)
at sun.security.ssl.CipherSuite$BulkCipher.isAvailable(CipherSuite.java:507)
at sun.security.ssl.CipherSuite$BulkCipher.isAvailable(CipherSuite.java:485)
at sun.security.ssl.CipherSuite.isAvailable(CipherSuite.java:190)
at sun.security.ssl.SSLContextImpl.getApplicableCipherSuiteList(SSLContextImpl.java:342)
at sun.security.ssl.SSLContextImpl.getDefaultCipherSuiteList(SSLContextImpl.java:300)
at sun.security.ssl.SSLSocketImpl.init(SSLSocketImpl.java:576)
at sun.security.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:512)
at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:73)
at com.somevendor.client.common.spring.remoting.http.e.createSocket(Unknown Source)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
at com.somevendor.client.common.spring.remoting.http.SecureHttpInvokerRequestExecutor.executePostMethod(Unknown Source)
at org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor.doExecuteRequest(CommonsHttpInvokerRequestExecutor.java:140)
at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.executeRequest(AbstractHttpInvokerRequestExecutor.java:136)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:192)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:174)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:142)
... 7 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
... 39 more
Caused by: java.lang.SecurityException: Toolkit not encapsulated by a jar.
at com.rsa.jcm.f.hq.a(Unknown Source)
at com.rsa.jcm.f.jg.b(Unknown Source)
at com.rsa.crypto.jcm.ModuleLoader.a(Unknown Source)
at com.rsa.crypto.jcm.ModuleLoader.load(Unknown Source)
... 43 more
Answering as I worked it out (5 years ago..). This exception happens when there is whitespace in the fully qualified path to the jar file that is been executed.
So this works:
/Users/stringy05/app/app.jar
But if you use a path with a space:
/Volumes/Macintosh HD/Users/stringy05/app/app.jar
Then it fails. When this originally happened I had a soft link in /Users/stringy05 to another hard disk, so either java or the OS was resolving the link path to the real path and it would fail.