I have a very similar error message to this post; however, the solution on that same post did not work for me. Editing the host file my adding in 127.0.0.1 my-host-name to my hosts file (per solution in linked thread) did nothing for me unfortunately.
After "run" in JDB, I get the following error message:
Initializing jdb ...
run run QuadtreeBitmap VM start exception: VM initialization failed for:
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/bin/java
-Xdebug -Xrunjdwp:transport=dt_socket,address=Patricks-iMac.local:50547,suspend=y
QuadtreeBitmap
ERROR: transport error 202: gethostbyname: unknown host ERROR: JDWP
Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP
exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
[debugInit.c:730]
Fatal error: Target VM failed to initialize.
I am using MacOS and trying to launch JDB directly through the terminal (and not through Eclipse or any other IDE).
In my case problem was related to Java 8. I used Java 9+ syntax for remote debugger:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
While for Java 8 you cannot use address in format *:port it suppose to be:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
The jvm is trying to open the dt_socket at host Patricks-iMac.local, port 50547 but needs first to resolve that host name to an IP address. DNS lookup will fail since it's a dummy hostname assigned to a private address and DNS servers usually don't know about them unless a sysadmin has configured them (companies use to do that). There are two solutions for this:
Add the hostname mapping on hosts file keeping other names configured for that IP
127.0.0.1 localhost Patricks-iMac.local
Configure the dt_socket by IP address without touching hosts file (recommended)
-Xrunjdwp:transport=dt_socket,address=127.0.0.1:50547
A word on networking troubleshooting:
unknown host means DNS problems, TCP connection did not start at all because an IP address was not available.
host unreachable means TCP connectivity problems, an IP is known but not reachable because of firewall, routing or other problems. ping to that IP will fail.
port unreachable means TCP connectivity problems, the IP is reachable but the port is not because of firewalls, service is down, etc. ping to the IP will work but connections to that port will still fail.
A word on security
The following syntaxes imply a security risk since the debug port will be exposed on all interfaces. Mitigation measures might be good to apply.
address=*:5005
address=0.0.0.0:5005
address=5005 (java 8, binds to loopback interface on java 9+)
May network admins made some changes in the meantime. Some firewall stuff. Problem is that Eclipse tries to establish connection to JVM at "localhost" (and some random port). You can try this solution.
Unable to debug in Java with eclipse
Related
So i was going to debug my Solr filter plugins on Intellij Community Edition. After i ran the program from comand prompt with this command
java -jar start.jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983
I started my Intellij debugger with this config:
Transport : socket
Debugger mode : attach
Host : localhost
Port : 8983
But when I ran the debugger I got this error:
Error running Debugger: Unable to open debugger port (localhost:8983):
java.io.IOException "handshake failed - connection prematurally closed"
Any idea how to fix this?
I got that error when trying to access to debug port on a Docker container.
If you are trying to access the debug port inside a Docker container make sure you are specifying the port as *:5005
E.g.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
This has been changes since Java 9.
See: REGRESSION: Remote debugging does not work on JDK 9
It's not a bug. It's a security.
Before the JDK-8041435
If you have a server with EXT and INT interfaces and start Java process with address=5900 it binds to both interfaces and allow anybody from entire world to connect to your java process unless you block it on firewall.
After JDK-8041435 socket transport try to guess localhost and bind to localhost only. I.e. socket transport by default works only if both client and server are located on the same machine. It's not an easy task to guess proper localhost. so ever same-machine configuration might not work in some situation because of network setup.
You can restore old, insecure behavior using * (asteric)
i.e.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5900
should work exactly as it was before JDK-8041435
But it's recommended to explicitly specify ip address to bind when it possible.
And JDWP socket connector accept only local connections by default
The JDWP socket connector has been changed to bind to localhost only if no ip address or hostname is specified on the agent command line. A hostname of asterisk (*) may be used to achieve the old behavior which is to bind the JDWP socket connector to all available interfaces; this is not secure and not recommended.
It should be something like this,
java "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983" -jar start.jar
it's working now
I had this error with OpenJDK 11 inside Docker container and setting environment variable JAVA_DEBUG_PORT to "*:5005" worked for me.
You forgot to specify -Xdebug on the java command line.
Edit: As in
java -jar start.jar -Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8983
It has helped me, at least in Intellij IDEA:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=0.0.0.0:5005
try to add ip 0.0.0.0.
I have a complicated application with several different JVMs.
JVM 1 does about 5 minutes of work and then fires off another JVM2 to do some extra work.
I want to Debug JVM2. So I turn on a remote socket debugger on JVM2's startup script:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
And I set up my Eclipse Remote Debug Session like this:
Connection Type: Standard (Socket Attach), Host: localhost, Port: 8000
If I wait for JVM2 to start, then launch the debugger, it works fine.
However it is REALLY hard to pay enough attention to click the debugger after 5 long minutes of waiting.
If I launch the remote debugger before JVM2 is on... I get
Failed to connect to remote VM. Connection refused.
Connection refused: connect
Is there someway to have the Remote Debugger continuously try to connect?
I tried to use the Eclipse Remote Debug Connection Type: Socket Listen but this blocks the port and JVM2 gives this error on startup:
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L500]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initialized
How can I have the remote debugger try over and over and over again?
Turning comment into answer for folks that come by later:
It's possible to specify server=n in the -Xrunjdwp switch and have the debugee connect as a client to the debugger server.
To make this work, the debugger configuration should be set up with the "Socket Listen" option in eclipse like so:
Client can then be started with:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=n,suspend=n,address=8000 -jar foo.jar
Or similar.
I have a servlet based application running on tomcat(7.0.53), oracle jvm (1.7.x) and CentOS(6.5).
There is a script that peridically "sainity checks" the application by issuing GET request to it (every 10sec).
I am encountering the following issue:
When under normal (moderate) load (~4k parallel connections), some of the sanity checks fail with connect timeout (approximately every 10th to 20th request fails).
The connection timeout configured on the client is 120s.
This is happning ONLY when connecting to 127.0.0.1 (loopback), connecting to <IP> of the real lan interface (eth0) does not have this issue*.
So:
curl <args> http://127.0.0.1:<port> fails,
curl <args> http://1.2.3.4:<port> does not fail.
Running tcpdump show that the server side does not send back SYN-ACK in the failed cases.
Note: Out of curiosity, I disabled IPv6 support (net.ipv6.conf.all.disable_ipv6 = 1) and the issue dissapeared.
Before, IPv6 is not used, but IPv6 for the loopback (lo) interface was initialized and the application was bound to all available interfaces (127.0.0.1, ::1 and <IP>).
On the eth interface IPv6 was not initialized at all.
What are the possilbe reasons for this kind of behaviour?
Any ideas for furthure troubleshooting this issue?
I am running a Java web application using tomcat to send generated reports via emails to the users.
I am able to send the emails but after few hours the server stops sending emails, with the following error.
javax.mail.MessagingException: Unknown SMTP host: mail.mydomain.co.uk;
nested exception is:
java.net.UnknownHostException: mail.mydomain.co.uk
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1970)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:642)
at javax.mail.Service.connect(Service.java:317)
at javax.mail.Service.connect(Service.java:176)
at javax.mail.Service.connect(Service.java:125)
at javax.mail.Transport.send0(Transport.java:194)
at javax.mail.Transport.send(Transport.java:124)
at com.turnkey.email.SendEmail.sendMail(SendEmail.java:119)
at com.turnkey.thread.CommunicationThread.run(CommunicationThread.java:399)
Caused by: java.net.UnknownHostException: mail.mydomain.co.uk
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:195)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:319)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:233)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1938)
... 8 more
After some time the server starts sending emails again.
Can anyone tell me what could be the problem.
And how do I solve this problem?
Thanks
This looks like a failure in your name service. The JDK isn't able to look up the host name to find its internet address. Since this works sometimes and not others, it looks like an intermittent failure of the name service. The name service failure could be due to some failure in your local operating system, or it could be due to some network failure communicating with your DNS server or other name service server, or it could be a failure in that DNS server or name service server itself. Determining the exact cause of the failure will require some debugging. Note that the JDK caches the results of name server lookups for some time so you'll need to factor that into your debugging.
Also make sure there is no space at the end of smtp hostname eg. mail.google.comSPACEHERE . Surprisingly this happened to me and finally after removing this space there was no complain about smtp host . Email was successfully sent
Set for host the ip address of the domain name instead of the domain name.
use nslookup mail.mydomain.co.uk on cmd to find the ip address.
It worked for me.
Specially for AIX or Linux OS environment,
We need to add the hostname in the etc/hosts file.. to sole this.
Windows operating system , this may work on Windows system as there is no strict security check however AIX or Linux must add host name to etc/hosts file in order for ping the SMTP server.
avoid doing this may lead Unknown host issue
I'm on a vista machine. I've started tomcat 5.5.27 with these options:
CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=9003 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false"
When I connect via jconsole and added the following service url
service:jmx:rmi:///jndi/rmi://localhost:9003/jmxrmi
it would not connect. Any ideas ?
Ok, I orignally supposed the URL given by op was wrong but it turns out no. So I can't answer.
Still, here are the basics:
For a simple connection through jconsole.
If you know that the JMX Server you want to connect to has the RMI registry port at 9003 for example, connect using
localhost:9003
instead.
Otherwise, here's what I found out from the ground up:
Suppose you have the JMX Server (alias 'JMX Agent' alias 'the JVM you want to connect to') running on 'TARGET MACHINE' with the RMI registry port at 'RMI REGISTRY PORT' and the JMX RMI server port at 'JMX RMI SERVER PORT'.
Note:
The RMI registry tells JMX clients where to find the JMX RMI server port; information can be obtained under key jmxrmi.
The RMI registry port is generally known as it is set through system properties at JVM startup.
The JMX RMI server port is generally not known as the JVM chooses it at random (if no other precautions are taken).
The following URI will lead to success (tested)
service:jmx:rmi://<TARGET_MACHINE>:<JMX_RMI_SERVER_PORT>/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi
This looks nasty. Let's cut it apart.
This URI is an RFC2609 "Service Location Protocol URL" (well, it's really an URI, right?)
It is composed of:
service - a constant
jmx:rmi - the service type composed of: abstract type jmx and URL scheme rmi
the rest - the sap (service access protocol specification)
sap is decomposed into:
//<TARGET_MACHINE>:<JMX_RMI_SERVER_PORT> - ipsite
/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi - URL part
A well-informed JMX client connects to the "ipsite" to do JMX-over-RMI exchanges; but what of the JMX client that doesn't KNOW that port? Patience...
URL part is decomposed into:
/jndi/ - This seems to tell the JMX client that it can get lookup information at the location that follows
rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi - Yep, we get information about the JMX RMI Server at the RMI registry, under the lookup key jmxrmi
This is somewhat cart-before-horse, as one has to contact the RMI registry given by the latter part of the SLP URL first.
After scratching head, intuitively, let's try:
service:jmx:rmi://<TARGET_MACHINE>/jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi
Yes, that works! The JMX RMI server port is nicely obtained from the registry. On second thoughts, the target machine should also be obtained from the registry, thus:
service:jmx:rmi:///jndi/rmi://<TARGET_MACHINE>:<RMI_REGISTRY_PORT>/jmxrmi
Even better, that works, too!
References:
1 download.oracle.com/javase/6/docs/api/javax/management/remote/rmi/package-summary.html
2 download.oracle.com/javase/6/docs/api/javax/management/remote/JMXServiceURL.html
3 mx4j.sourceforge.net/docs/ch03s04.html
4 download.oracle.com/javase/6/docs/technotes/guides/management/agent.html#gdevg
5 http://www.rfc-editor.org/rfc/rfc2609.txt
On Ubuntu 10.04, using OpenJDK 6 and Tomcat 6.0.29, I was unable to activate JMX for a local jconsole session, no matter how many com.sun.management.jmxremote.* options I passed to java with CATALINA_OPTS. The problem was the -Djava.io.tmpdir setting, which defaults to $CATALINA_BASE/temp. I simply had to set:
CATALINA_TMPDIR="/tmp"
at the beginning of bin/catalina.sh and I was able to connect locally with jconsole, jmap, jps etc. There was no need for any com.sun.management.jmxremote.* settings at all.
Are the processes run under the same user?
You can also check by running jps and jconsole (both in the JDK_HOME/bin directory)
This is also needed for OS X 10.7 aka Lion.
I answered a similar question here:java.rmi.ConnectException: Connection refused to host: 127.0.1.1;
I found many of the Q&A on this topic, not nothing was helping me - that's because my issue was more basic ( what can I say I am not a networking guru :) ). My ip address in /etc/hosts was incorrect. What I had tried included the following for CATALINA_OPTS:
CATALINA_OPTS="$CATALINA_OPTS -Djava.awt.headless=true -Xmx128M -server
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=7091
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=A.B.C.D" #howeverI put the wrong ip here!
export CATALINA_OPTS
My problem was that I had changed my ip address many months ago, but never updated my /etc/hosts file. it seems that by default the jconsole uses the hostname -i ip address in some fashion even though I was viewing local processes. The best solution was to simply change the /etc/hosts file.
The other solution which can work is to get your correct ip address from /sbin/ifconfig and use that ip address when specifying the ip address in, for example, a catalina.sh script:
-Djava.rmi.server.hostname=A.B.C.D