[
https://issues.apache.org/jira/browse/NETBEANS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177351#comment-16177351
]
Peter Hansson commented on NETBEANS-63:
---------------------------------------
Well, not quite done.
We will have to move *both* the initialization of ProxySelector and the
initialization of Authenticator to _before_ the modules are initialized
(meaning before the point were ModuleInstallers are executed and @OnStart are
spawned).
To re-iterate, the current order is:
# Main thread: Modules initialization: All {{ModuleInstall#restored()}} are
executed sequentially. {{@OnStart}} tasks are spawned (in parallel) and then
waited for.
# Main thread: ProxySelector is initialized and registered
# AWT thread: Main Main window is initialized and displayed. This will release
those tasks waiting for {{WindowManager.invokeWhenUIReady()}}.
# Main thread: WarmUp tasks are spawned
# Main thread: Authenticator is initialized and registered
Proposed order:
#2 and #5 moved to right before #1. The order of ProxySelector and
Authenticator is irrelevant, either can go first. (most logical to have
ProxySelector before Authenticator as today, I think)
Much simpler than my original idea (thanks!) and not creating any penalty which
is not already present. Previous ideas were, as Jaroslav put it, overkill.
Please comment on proposal and I'll prepare PR if appropriate.
Funny you should mention that Authenticator should be pluggable. Please see
[NETBEANS-61|https://issues.apache.org/jira/browse/NETBEANS-61]. I had launched
that as an issue of its own since before this one, and it already has a Pull
Request. It is strictly speaking another case, therefore two tickets.
Btw: Anyone plugging in their own ProxySelector or (in the future also) their
own Authenticator should be painfully aware that they are on the critical path
of startup so need to be fast in constructor. That is also the case today. My
[own ProxySelector|https://bitbucket.org/phansson/netbeansproxy2] defers most
initialization to first use because it needs to download the PAC file to be
usable. I don't know if there's a suitable place to document that
initialization of ProxySelector and Authenticator has a 1:1 impact on startup
time ?
> Incorrect startup order
> -----------------------
>
> Key: NETBEANS-63
> URL: https://issues.apache.org/jira/browse/NETBEANS-63
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Module System
> Affects Versions: 8.2, 9.0
> Environment: All
> Reporter: Peter Hansson
> Attachments: NBStartup.pdf
>
>
> As part of analyzing the [freeze bug on
> startup|https://issues.apache.org/jira/browse/NETBEANS-58], I've come across
> something I see as a problem in NB startup sequence.
> Basically I see this sequence in the Platform's main startup thread:
> # @OnStart tasks from modules are spawned
> # ProxySelector is registered
> # WarmUp tasks are spawned
> # Authenticator is registered
> So clearly, tasks that may perform network operations are started _before_
> network infrastructure ({{ProxySelector}} and {{Authenticator}}) has been
> initialized. In real-life it will be hit and miss which comes first.
> I've attached my analysis of the startup sequence as a PDF (in case anyone
> disagrees).
> My idea for a fix is along these lines:
> * I want to continue to allow @Startup tasks and WarmUp tasks to be launched
> early (as today), but a task must itself be aware if it needs network or UI
> initialization or whatever.
> * I want to create a new {{RunLevel}}. Currently the RunLevel feature is
> under-used in my experience. There's really only one RunLevel at the moment,
> namely the {{GuiRunLevel}} which is always executed last. (despite the name
> it applies both to GUI and headless scenario). So I would add an additional
> RunLevel, {{NetworkRunLevel}}, where network infra will be initialized. The
> new RunLevel will run before GuiRunLevel. This mimics what operating systems
> does and I believe this was also the original idea of the RunLevel feature.
> * Currently RunLevels are found by Lookup so that anyone can install their
> own RunLevel. I don't think this feature is used (it probably requires to be
> Friend), but it is nice and we should of course still cater for it.
> * Create a public interface where a task can wait for a given RunLevel to
> have executed. I'm thinking some kind of annotation or something.
> * Existing WarmUp tasks will need to be amended to clearly indicate at what
> RunLevel they can execute. (default will be that all RunLevels have
> executed). Module tasks (@OnStartup) will also need to be catered for.
> Ideas, comments, please. There may be simpler ways of solving the problem but
> we should really keep an eye on allowing to start tasks as early as we allow
> today (i.e. not make startup performance worse).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
