Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Initial Bulk Hot Deploy
Initial Bulk Hot Deploy [message #1714848] Tue, 17 November 2015 09:34 Go to next message
Felix Schöpf is currently offline Felix SchöpfFriend
Messages: 14
Registered: February 2013
Junior Member
On our Ubuntu Dev-Server we have a Virgo instance (3.6.4) with 35 Plan files. Whenever we restart the Server or the Virgo instance, Virgo fails to successullfy deploy all these plans. Some remain in resolved state.
The Plans are successfully deployed when I touch the corresponding plan files. So we think the problem is the sheer amount of plans.

We do have other Virgo instances with less plan files, which startup with no problems at all.

The docs (section 12.1) mention the initial bulk hot deploy, which can be disabled by removing "org.eclipse.virgo.fschecker.initialEventMode=bulk" from $SERVER_HOME/configuration/config.ini.
Unfortunately the config.ini does not contain such a line, hence, we can't remove it.
Is there a different config parameter or another possibility to not deploy all plans in parallel?

Report message to a moderator

Re: Initial Bulk Hot Deploy [message #1714860 is a reply to message #1714848] Tue, 17 November 2015 11:02 Go to previous messageGo to next message
GianMaria Romanato is currently offline GianMaria RomanatoFriend
Messages: 57
Registered: November 2015
Member
Hello,

you can move your 35 plan files from the pickup folder to one of the repository folders and then have a "main" plan in the pickup folder which internally lists all the 35 plans by name.

Make sure you use the value of the plan name attribute and not the file name.

In this way all plans will be activated sequentially, following the order in which they are listed in the "main" plan:

    <artifact type="plan" name="plan1"/>
    <artifact type="plan" name="plan2"/>
    <!-- all other plans -->
    <artifact type="plan" name="plan35"/>

Report message to a moderator

Re: Initial Bulk Hot Deploy [message #1715016 is a reply to message #1714860] Wed, 18 November 2015 14:00 Go to previous messageGo to next message
Felix Schöpf is currently offline Felix SchöpfFriend
Messages: 14
Registered: February 2013
Junior Member
Hi GianMaria!

Thank you for the input. Very interesting idea!

Unfortunately, the list of plans is rather dynamic. We do build with jenkins and use a custom maven plugin to deploy to the Virgo. I think your suggestion is not applicable for this environment.

Meanwhile, I tried to reproduce the problem on a Windows machine with no luck.

The problem occurrs on a virtual Ubuntu 14.04.3. We do get the following error messages:
 ERROR start-signalling-26          org.eclipse.virgo.medic.eventlog.default                         DE0006E Start failed for bundle 'a.c.p.b.m-5.12-a.c.p.w.c.d' version '5.12.0.201511181240'. org.springframework.context.ApplicationContextException: Application context initialization for 'a.c.p.b.m-5.12-a.c.p.w.c.d' has timed out waiting for (|(objectClass=a.c.p.d.IDSettings)(objectClass=a.c.p.d.IQDao)(objectClass=a.c.p.d.IQTDao)(objectClass=a.c.p.d.IPDao)(objectClass=a.c.p.d.IUDao)(objectClass=a.c.p.d.IUSDao)(objectClass=a.c.p.d.ICFCDao)(objectClass=a.c.p.d.IRDSGDao)(objectClass=a.c.p.d.IPDVDao)(objectClass=a.c.p.i.d.m.PMDTVMapper)(objectClass=a.c.p.d.IWDao)(objectClass=a.c.p.d.ISIDao)(objectClass=a.c.p.d.ISDao)(objectClass=a.c.p.d.ICEDao)(objectClass=a.c.p.d.ISTPDao)(objectClass=a.c.p.d.ICSCDao)(objectClass=a.c.p.d.ICHDao)(objectClass=a.c.p.d.IPQTDao)(objectClass=a.c.p.d.ISTPIDao)(objectClass=a.c.p.d.ICPDRDao))
        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:489)
        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:54)
        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:109)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)


So the bundle is waiting for the services and as it lasts too long a timeout occurs.

Do you have any further hints on how to resolve this problem?

Best regards,
Felix

Report message to a moderator

Re: Initial Bulk Hot Deploy [message #1715022 is a reply to message #1715016] Wed, 18 November 2015 14:35 Go to previous messageGo to next message
GianMaria Romanato is currently offline GianMaria RomanatoFriend
Messages: 57
Registered: November 2015
Member
Hello Felix,

if I am not mistaken you are using blueprints.

Quoting the Apache Aries documentation [1], "The object that is injected for a reference is actually a proxy to the service registered in the service registry. A proxy enables the injected object to remain the same while the backing service can come and go or be replaced with another service. Calls on a proxy that does not have a backing service will block until a service becomes available or a timeout occurs at which point a ServiceUnavailableException will be thrown."

At first sight, it may be that you are experiencing the timeout described above.

The timeout can be configured as explained in the Gemini Blueprint documentation [2], section 8.1 and 8.2 and may come handy in case your problem originates from a very slow application start.

Have you considered the possibility that the application is experiencing some deadlock during bootstrap/initialization and that because of that the blueprint container will timeout waiting for services to become available? Or that maybe the wiring of services may result in the "dining philosophers problem".

[1] aries.apache.org/modules/blueprint.html
[2] https://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/app-deploy.html

GianMaria.

Report message to a moderator

Re: Initial Bulk Hot Deploy [message #1716096 is a reply to message #1715022] Tue, 01 December 2015 09:45 Go to previous message
Felix Schöpf is currently offline Felix SchöpfFriend
Messages: 14
Registered: February 2013
Junior Member
Hi GianMaria!

Sorry for the late answer.
It's definitely no deadlock problem, but a timeout problem. And I don't really want to adjust the timeout, just because the timeout can occur if Virgo deploys multiple/too many plans concurrently.
As far as I can see, there would be no problem, if Virgo would only deploy two or three plans in parallel.

I have the feeling that it could work if we could somehow set the synchronous var of org.eclipse.virgo.nano.deployer.api.core.DeploymentOptions. Maybe I will try that if I somewhere find some more time for doing it. Wink

Anyway, thank you for your feedback.

Best regards,
Felix

Report message to a moderator

Previous Topic:Duplicate jars
Next Topic:Problem with Spring NamespaceHandler
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Apr 19 10:58:21 GMT 2024

Powered by FUDForum. Page generated in 0.03123 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly