[
https://issues.apache.org/jira/browse/NETBEANS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177679#comment-16177679
]
Jaroslav Tulach commented on NETBEANS-63:
-----------------------------------------
Moving #2 and #5 right before #1, seems OK to me. As you mentioned, it comes
with no additional penalty.
Re. documentation. That would indeed be great. We have {{arch.xml}} files with
{{use-cases}} sections - e.g. sample of registering own {{ProxySelector}}
and/or {{Authenticator}} could go there. Otherwise there is
[NetworkSettings|http://bits.netbeans.org/dev/javadoc/org-openide-util-ui/org/openide/util/NetworkSettings.html]
class that seems related.
> 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)
