Community
Participate
Working Groups
Version: 3.3.0 Build id: I20070323-1616 Europa: all but 3 projects / features context: - workspace contains all WID plugins (1600+ projects) - activating Resources perspective only (no other active perspective) - use instrumented core.runtime to monitor plugin activation test: - start europa, and wait until jdt tool initialization is complete - do nothing else From the (to_be_attached) resulting trace files, starting europa against the same wks using the very same perspective sometimes activates 63 plugins, sometimes 83. --> do we expect 63 or 83 plugins to load? --> note that when "only" loading 63 plugins, we gain 3 sec on startup times. Note that base M6 Eclipse is stable, activating 32 plugins I'll attach some files (trace, .log, diff screen shot) From the .log, it sounds like Mylar is having some troubles.
Created attachment 67363 [details] [screen shot] plugins that fail to load
Created attachment 67364 [details] [file] .log file
Created attachment 67365 [details] [file] plugin activation trace files
Also note that I performed similar tests using the Java and PDE perspectives, and did not encounter the same issue: the number of activated plugins was stable - 68)
Added Mik, since one of the causes for some plug-ins not being loaded is the timeout from Mylar: !MESSAGE While loading class "org.eclipse.mylar.context.core.ContextCorePlugin", thread "Thread[main,6,main]" timed out waiting (5000ms) for thread "Thread[Worker-2,5,main]" to finish starting bundle "update@plugins/org.eclipse.mylar.context.core_2.0.0.v20070403-1300.jar [569]". To avoid deadlock, thread "Thread[main,6,main]" is proceeding but "org.eclipse.mylar.context.core.ContextCorePlugin" may not be fully initialized. So, I guess the higher number would be the "normal" state. Remains the question why that many plug-ins need to be activated in this scenario.
Created attachment 67398 [details] [file] plugin activation trace file Another trace file (same startup scenario) - this time 96 plugins were loaded
I will try to replicate this for Mylar and have seen those message a while back, though they don't typically cause failures. However, note that the version is 2.0.0.v20070403 and I'll be trying it with the current 2.0.0.v20070514.
Mik, I guess the fixed state will be that the Mylar and those referenced by it will be loaded, right? If so, could you rewrite your code to not activate all those plug-ins until those that you want to hook into are loaded through user interaction? This can be done by registering a bundle listener in a base Mylar plug-in's start() method.
The messages in comment 5 happen when two bundles are trying to start another bundle. This in turn happens typically when the bundle being started takes too long in its activator. The way to solve this (and improve performance) is to stop doing so much work in the activator.
Jeff: the thing that I don't get about this problem (also reported on bug 188524) is that we have only noticed it happen on the first restart via the update manager, and not subsequently. Also, I am not aware of bad behavior that it causes. The Update Manager connection made me suspect that this is a result of the shell being killed (bug 107280) in case some OSGi registry is expecting SellListener.shellClosed() or some other event to be fired. Or perhaps it is just that the first start of our bundles is slower? Due to startup failures that Mylar used to have around 1.0 we have tried to move a bunch of work from happening synchronously in the activator. However, our current architecture requires Mylar Connectors (e.g. Bugzilla) to be loaded before the Task List is read. And since in our UI design the Task List contents are as important to show on startup as Workspace resource contents and task editors need to be restored, we cause connector plug-ins to be initialized on startup. So far we have been successful at minimizing the effects of this. Since we are likely stuck with this architecture for 2.0 I will investigate whether we can minimize what happens on activation (via bug 188524).
ok. I don't have any particular insight here. I would observe however that a common approach for avoiding things like task list population on activation is to defer the work and do it incrementally in a different thread (or some such). this allows the UI to paint and the system to continue starting while the content is incrementally filled in. Another option is to move the initialization of whatever structures are being initialized to be done lazily on access rather than aggressively on activation. That way the it is the first accessor's thread that pays for the work not the Main thread at startup. Anyway, my intention was not to get into the details here but rather just point out the underlying issue at play.
(In reply to comment #10) (...) " is that we have only noticed it happen on the first restart via the update manager, and not subsequently. " (...) Mik, I noticed this issue while taking europa startup measures: my europa config was 'long' installed and was not in the case of a re-start after install
(In reply to comment #11) > That way the it is the first accessor's thread that pays for the work not the Main thread at startup. Thanks Jeff. We already do the bulk of the work asynchronously in another thread and I will investigate whether I can push any more of it off. (In reply to comment #12) > I noticed this issue while taking europa startup measures: my europa config was > 'long' installed and was not in the case of a re-start after install I'm not sure I know what you mean by 'long' installed?
I suspect that he means it was installed along time ago, not just installed using update.
(In reply to comment #14) by 'long' I was meaning that I had started / stopped europa many times, and the problem did not occur right after the update part of the install. Typical scenario is: - unzip base eclipse (M6) - start eclipse, go to the update site and install all installable features - re-boot as requested - stop europa - re-start and observe
Jeff: could there be a bad interaction between the plug-in registry/launching and Update-based restart (which does not close the workbench normally, bug 107280)? Eric: next time you're testing you could try saying "No" to the Update Manager's restart recommendation and restart the workbench as usual. But given the latest comments on bug 107280 I think that we're stuck with the current behavior.
certainly if you shutdown incorrectly then on restart various recovery strategies may get triggered resulting in more code loaded and plugins activated.
(In reply to comment #16) While performing some europa install tests at M7 level (the was opened at M6 level), performed some install variation (reply no to the restart request after feature install). Sounds like this was a transient issue as the number of activated plugins is now stable (88). As I cannot reproduce the issue anymore, please feel free to close this bug.
I'm still somewhat concerned about this, but will explore my concerns on Mylar bug 188524 where I will try to figure out if there is anything that we could be doing to avoid the warnings other than starting faster. Whenever we have had this happen or had it reported happen the problem has happened on Update Manager based restart, has not caused any problems, and has been transient. We did just hear about a possible deadlock (Mylar bug 189054) which I'm investigating but it's not clear that's related.
I'm closing this bug as Europa has shipped. If there continue to be issues, please reopen this bug or, better yet, with the individual projects involved.
