With JRE6 (SUN VM on Windows XP), getLocalhost() freezes sometimes.
Interestingly, if in the debugger in Eclipse, it does not freeze. I narrowed it down to a single getLocalhost() call using old school println. There is nothing particularly special about the code, that I can see.
Has anyone else seen this problem?
You did not specify how long it freezes for... or did you mean completely frozen, never returning.
If the local host name (returned from a JNI call) is not "localhost", the IP address for the local name is resolved using InetAddress.getAddressFromNameService(). This is a DNS call that could conceivably block for an unspecified amount of time finding and accessing the name server.
Use wireshark to see if your DNS is taking a long time to respond.
Related
I'm running a program using rmi on Windows. I noticed that sometimes remote method invocations take as long as 2 seconds to return. I also tried running the same program on a Mac machine, and the latency is on the scale of milliseconds. I found this article that says the network needs to be set to private on Windows, otherwise connections would be slow. I tried setting the network to private and unfortunately it did not solve my issue. I've been struggling with this issue for days. Is there any other reason why rmi is so slow on Windows? What might I be missing here?
I have a jboss server running continuously, but after a day or two, it stops saying "Press any key to continue" in the console. I have checked the log file as well but there is no exception. Though the question looks abstract but if any of you have come across this can share any help.
Thanks
I assume you're using Windows. You could try setting the environment variable mentioned in this documentation:
https://docs.jboss.org/author/display/AS71/CLI+Recipes#CLIRecipes-Windowsand%22Pressanykeytocontinue...%22issue
But i'm not sure it will help. It's not clear that there is a connection between the batch interpreter asking you to press a key to continue, and JBoss terminating.
The best solution would obviously be to work on Unix instead of Windows, but i imagine that is out of scope!
I am reading here, that
On connect, the JVM (Java Virtual Machine) tries to resolve the
hostname to IP/port. Windows tries a netbios ns query on UDP (User
Datagram Protocol) port 137 with a timeout of 1.5 seconds, ignores any
ICMP (Internet Control Message Protocol) port unreachable packets and
repeats this two more times, adding up to a value of 4.5 seconds. I
suggest putting critical hostnames in your HOSTS file to make sure
they are resolved quickly. Another possibility is turning off NETBIOS
altogether and running pure TCP/IP on your LAN (Local Area Network).
is this currently an issue still? Because I am working on a heartbeat-sensor and I was curious.
Your citation is not a normative reference, just another hobby site, and in this case it is dead wrong. None of this has anything to do with setSoTimeout(). He is totally confused between name resolution time, connect time, and read time. setSoTimeout() sets a read timeout, and is unaffected by the shenanigans he describes, whether accurately or otherwise, which wouldn't even happen at connect time as he states: they would happen at name-resolution time.
It's far from the only confusion to be found on that site, or even on that page, let me assure you. I told him about several errors on this page ten years ago, and about quite a lot of others, all of which remain uncorrected to this day, which gives you an idea of the site's accuracy, up-to-date-ness, and content review mechanisms. His only response was to add a rude remark about me. Unconvincing as a peer review mechanism.
Stick to authoritative sources.
I'm working in Groovy 1.8.6, running on JDK 1.6.0u33. When my program is starting up, it attempts to connect to another process on the same host by connecting to a telnet port on the host address. It uses the standard Java class InetAddress to determine the local host address. However, for some reason when I start the program up on a Windows XP VM, the host address resolves to garbage and the connection fails.
The startup script includes this line for diagnostic information:
def serverAddress = "http://${InetAddress.localHost.hostAddress}:${config.ServerPort}/DigitizerService?wsdl"
The output when serverAddress is printed to the terminal is:
http://0.1.0.5:8989/DigitizerService?wsdl
The address is not always the same- another time it came out as 0.2.0.5. But it always comes out as something that's not even a valid address, let alone the actual address for this host.
This same codebase is in production on a large number of boxes out in the wild and I've never seen an issue like this coming up, so I guess it must be specific to this new devbox it's on- or it's a bug in the new JDK.
Does anyone have any idea what might be causing something so basic as this to output garbage? Thanks in advance.
While I tried restarting before posting this question (of course, this is Windows after all), and it did not help, a second reboot of the VM seems to have fixed the issue. It was in the process of installing a big pile of Windows updates, as it was an old VM that I'd just dusted off, so I suppose that may have somehow scrambled things internally in the OS.
So I'm still very confused as to how this came about, but I think I can conclude that it was not Java at fault. Probably.
I've been working on a Java project for year. My code had been working fine for months. A few days ago I upgraded the Java SDK to the newest version 1.6.0_26 on my Mac (Snow Leopard 10.6.8). After the upgrade, something very weird happens. When I run some of the classes, I get this error:
Invalid memory access of location 0x202 rip=0x202
But, if I run them with -Xint (interpreted) they work, slow but work fine. I get that problem in classes where I use bitwise operators (bitboards for the game Othello). I can't put any code here because I don't get an error, exception or something similar. I just get that annoying message.
Is it normal that the code doesn't run without -Xint but it works with it? What should I do?
Thanks in advance
When a JVM starts crashing like that, it is a sign that something has broken the JVM's execution model.
Does your application include any native code? Does it use any 3rd-party libraries with native code components? If neither is true, then the chances are that this is a bug in the Apple port of the JVM. It could be a JIT compiler bug, or a bug in some JVM native code library.
What can you do about a bug like that?
Not a lot.
Reduce your application by progressively chopping out bits until you have a small testcase that exhibits the problem.
Based on the testcase, see if there's some empirical way to avoid the problem.
Submit a bug report to Apple with the testcase.
I just came across this situation and it turned out to be related to a piece of code that was serializing a JSON object with a cyclic reference to itself. I removed the cycle and the error went away. I suspect this is related to a memory overflow error that is now handled differently by newer JVMs on Mac OSX. In this case, I was running Mac OSX 10.7.
For completeness the errors I was receiving were:
Invalid access of stack red zone 0x10e586d30 rip=0x10daabba6
Bus error: 10
And:
Invalid memory access of location 0x10b655890 rip=0x10a8baba6
Segmentation fault: 11
Also verify that you are building the GUI on the event dispatch thread and never updating a GUI component from any other thread.
Related errors are notoriously hard to reproduce, but the change associated with altered timing is suggestive.
Please check if /etc/hosts is empty and verify that it include these configurations ：
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost