This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
o.n.CLIHandler creates new SecureRandom to crypt communication. This is sometimes very expensive. If there is a problem with DNS it can take tens of seconds or even minute before startup can proceed. During this time java.net.Inet4AddressImpl.getLocalHostName is waiting for result and all other processing is blocked.
Do you know how to reproduce?
Why me? My original code used Random. You have introduce secure random before merge of my branch for reasons I do not remember.
Well, because Random isn't secure, of course. :-) I know I added that code but I thought you might have more time to look at it.
Haven't seen any details on when and why it is slow. No apparent alternative anyway (need a secure random number here); if there is a problem in the SecureRandom implementation it would need to be filed as a JRE bug.
no further comments - closing.
Why is it slow: on Linux (and Solaris) it initializes network and resolves hotsname through DNS. On my Ultra-20 this can take 0-10 seconds because for some reason JRE thinks that I have IPv6 configured. Even without init of IPv6 it can take similar time while talking to network. On Windows there is another expensive operation that accesses I/O devices. I will attach Sandip's comment on this. If we really think we need to secure CLI handler let's move the init from critical path of startup sequence. If we are lucky it can be processed asynchronously sooner than another code tries to read InetAddress of machine (IDESettings during proxy updating - probably called as a side-effect when checking for MDI/SDI mode, or AU module needs to know this data).
Created attachment 30533 [details] Sandip's mail
CLIHandler is Yarda's code. Would be WONTFIX except for Radim's suggestion of doing this initialization asynchronously - not sure if that is actually possible in this case, but perhaps.
SecureRandom is computed asynchronously. /shared/data/ccvs/repository/core/bootstrap/src/org/netbeans/CLIHandler.java,v <-- CLIHandler.java new revision: 1.46; previous revision: 1.45 done Checking in test/unit/src/org/netbeans/CLIHowHardIsToGuessKeyTest.java; /shared/data/ccvs/repository/core/bootstrap/test/unit/src/org/netbeans/CLIHowHardIsToGuessKeyTest.java,v <-- CLIHowHardIsToGuessKeyTest.java new revision: 1.5; previous revision: 1.4 done Checking in test/unit/src/org/netbeans/CLIHandlerTest.java; /shared/data/ccvs/repository/core/bootstrap/test/unit/src/org/netbeans/CLIHandlerTest.java,v <-- CLIHandlerTest.java new revision: 1.10; previous revision: 1.9
Not quite done: 1. apisupport/harness/release/run.xml still passes the now-obsolete switch -J-Dorg.netbeans.CLIHandler.fast.random=true 2. And core/arch/arch-core-launcher.xml still mentions it. Also, minor but: is the field/var identifier 'parael' supposed to mean something? Did you mean 'parallel' perhaps?
Should not the property be rather kept for apisupport puproses?
If you are doing the secure number generation asynch, then I don't see why apisupport would need to have the tested app behave any differently than normal. Issue #70939 was basically about wanting to avoid the performance hit for security while developing an app, but if the performance hit is now gone, then you might as well have the security.
#44083: Removing friend api between CLIHandler and apisupport to speedup startup in development mode, as the startup shall be now fast enough" Checking in core/arch/arch-core-launcher.xml; /shared/data/ccvs/repository/core/arch/arch-core-launcher.xml,v <-- arch-core-launcher.xml new revision: 1.47; previous revision: 1.46 done Removing core/bootstrap/test/unit/src/org/netbeans/CLIDoesNotQuerySecureRandomTest.java; /shared/data/ccvs/repository/core/bootstrap/test/unit/src/org/netbeans/CLIDoesNotQuerySecureRandomTest.java,v <-- CLIDoesNotQuerySecureRandomTest.java new revision: delete; previous revision: 1.5 done Checking in apisupport/harness/arch.xml; /shared/data/ccvs/repository/apisupport/harness/arch.xml,v <-- arch.xml new revision: 1.6; previous revision: 1.5 done Checking in apisupport/harness/release/run.xml; /shared/data/ccvs/repository/apisupport/harness/release/run.xml,v <-- run.xml new revision: 1.24; previous revision: 1.23