Eclipse Community Forums: Virgo » Initial Bulk Hot Deploy

Home » Eclipse Projects » Virgo » Initial Bulk Hot Deploy

Initial Bulk Hot Deploy [message #1714848]

Tue, 17 November 2015 04:34

Eclipse User

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?

Re: Initial Bulk Hot Deploy [message #1714860 is a reply to message #1714848]

Tue, 17 November 2015 06:02

Eclipse User

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"/>

Re: Initial Bulk Hot Deploy [message #1715016 is a reply to message #1714860]

Wed, 18 November 2015 09:00

Eclipse User

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

Re: Initial Bulk Hot Deploy [message #1715022 is a reply to message #1715016]

Wed, 18 November 2015 09:35

Eclipse User

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.

Re: Initial Bulk Hot Deploy [message #1716096 is a reply to message #1715022]

Tue, 01 December 2015 04:45

Eclipse User

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

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

Goto Forum:

-=] Back to Top [=-

Current Time: Sun May 11 22:13:19 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter