Re: [virgo-dev] Slow startup, deploying "transitively complete" applicat

[Glyn Normington <gnormington@xxxxxxxxxx>]

Hi Peter

I just realised the same thing about forum notifications. Apologies! I posted a short response there, but virgo-dev seems a lot safer for these kinds of discussions that will be of particular interest to Virgo developers.

I will wait for Dmitry's findings before scheduling any time to look at the slow deployment, but I'm certainly interested in progressing this. Please raise a bugzilla to keep this on our radars. You may also want to raise a bugzilla to capture the requirement to deploy plans which are meant to be transitively complete (i.e. to fail rather than auto-provision missing transitive dependencies) - that sounds like a requirement others will like.

Steve Powell is reworking the patch in bug 315162 and may care to comment when he makes a bit more progress. We don't expect a big improvement, but it was such a localised patch that it seemed worth making at this stage.

Nikolai from SAP is particularly interested in more radical *startup* performance improvements, but speeding up general deployment could also help startup. If you want to know more, ask here or join in next week's community call (details on the wiki). I have asked Nikolai to share any findings from their profiling work so we can start to build up more understanding of the problem. Perhaps the SpringSource team's problem is that our development machines are simply too fast and we didn't feel enough personal pain during 2.0 development to bother spending a lot of time profiling as we had higher priority work items to keep us occupied.

As for new artifact types, this is certainly something we want to enable and encourage. IIRC I fed Dmitry some information to get him started so I'll let him recap that. I don't think it is essential to cast to an internal type - I think that was just a convenience for certain built-in deployment types - but if we need some kind of helper class, I'm happy to consider suitable refactorings. Depending on how complete Dmitry's notes turn out to be, you may like to raise yet another bugzilla to make sure the information is forthcoming.

Once again: apologies for the slow response. I appreciate you raising these important topics and am happy to help work them through.

Glyn

On 2 Jun 2010, at 19:25, Dmitry Sklyut wrote:

Hi Peter,

I just realized that forum is not notifying me when there are new replies, only new threads.

To give a quick update.  I did not get the time to do what I wanted with profiling of the application.  I will pick up your pom and give it a try later this week.  This is a much simpler set-up than the 5 plan thing that I have :)

There is a bugzilla issue that might interest you - https://bugs.eclipse.org/bugs/show_bug.cgi?id=315162.  A claim of 5-7% start up improvement.

On question 3 - it is possible right now to create new deployment artifact types.  I will have to dig out my research on this subject and will follow to the list.  There was one thing that scared me along the way, is that some transformers cast to an Abstract implementation of DeploymentArtifact (or something like that) and that class was in an internal package.  My impression was that any new deployment artifact type must be created as a fragment bundle.  I will find details and post them here.

Regards,

Dmitry

2010/6/2 Peter Gardfjäll <peter.gardfjell@xxxxxxxxx<mailto:peter.gardfjell@xxxxxxxxx>>
Hi,

I've made a couple of posts on the forum thread
 http://www.eclipse.org/forums/index.php?t=msg&th=167723&start=0&;
without receiving a reply.

Maybe my posts have passed unnoticed (or could the poor response be
due to lack of interest?).
Anyhow, I thought I'd try my luck on the mailing list instead.

Basically I have three questions:

(1) Has there been any progress in investigating the "slow startup issue"?

(2) Also, Glyn, in the original forum thread (at Spring dm,
http://forum.springsource.org/showthread.php?t=86495&highlight=launcher.bundles)
you mentioned ideas about providing support for deploying
"transitively complete" applications/subsystems. Is this on Virgo's
roadmap?

(3) Finally, I assume that it is possible to hook in additional
deployers (handling new types of deployment artifacts) in Virgo. If
this is the case, I'd appreciate any pointers on how to get started
(what interfaces need to be implemented, what design guidelines should
be adhered to, etc)?

Thanks, Peter
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev

<ATT00001..txt>