Summary: | Java/JRE takes about 5 minutes to load an applet | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom Wesley <tom> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED CANTFIX | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Not workiong output of iptables -L generated by shorewall
working version created by firestarter |
Description
Tom Wesley
2004-07-14 00:46:57 UTC
OK, some additional information thanks to DrChandra in chat. Seems to have been related to the repeated poll: socket(PF_UNIX, SOCK_STREAM, 0[pid 17113] socket(PF_UNIX, SOCK_STREAM, 0) = 8 [pid 17113] connect(8, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19[pid 17113] connect(8, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19) = 0 So it looks as though something is trying to connect to the X server. Also, the full 86MB strace log bzip2's to ~500K if it will be of use to anyone. OK, seems it was a recent update to shorewall that caused the problem. Stopping shorewall didn't solve the problem, but restarting after removing it from the runlevel did. I'd love to know why, if anyone knows why? It makes sense that it was trying to connect to X -- the Control Panel requires X and should need to connect, yes? In any case, I'm not sure why the apparent conflict exists with shorewall -- I don't use it. However, I didn't see listed which JVM (runtime) you are using. Maybe throwing that out would be helpful to someone, at the least. I tried pretty much all of the JVM/JRE's in portage, including the beta 1.5 from Sun. It's perfectly replicatable here, and is probably something I am doing with shorewall. If someone wants to try then use the webmin configuration for shorewall (latest ~2.0.6 still has the problem) and set it up for a single interface to the internet, not other card at all. Almost certainly what is happening here is that Shorewall is blocking your local X server connections. The ControlPanel needs an X connection to launch, but for some reason either Shorewall or IPTables in the kernel is blocking it. I'm assuming that you can launch other applications just fine. In that case, it may have something specific to do with the way X sockets are used by Java runtimes, but I'm not sure. I suggest taking a look at your IPTables rules after Shorewall starts. It is probably inserting a bunch or rules, one of which is blocking the JRE from accessing the X server. This would also explain why rebooting after stopping shorewall seemed to allow normal connections again. You can usuaully view IPTables rules by using the following command: iptables -L Further debugging may need to be done with iptables folks. But it seems almost certain that this is the problem. If so, it's not Java's fault and this issue should be reassigned or resolved. Thanks for the additional information, and I agree with what you're saying. I have to admit to having forgotten about this bug report as I solved the issue by not using Shorewall. I'll attempt to resolve/reassign this in the morning. Have a nice bugday... ;) Created attachment 37242 [details]
Not workiong output of iptables -L generated by shorewall
Created attachment 37243 [details]
working version created by firestarter
not a java bug, and those shorewall rules look seriously broken I have had a very similar problem which was related to iptables rules, too. Finally, I allowed the localhost (127.0.0.1) as source address to connect to localhost as destination address using the icmp protocol thus the loading time of java applets almost disappeard. |