Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 337846

Summary:	Installing a plan and bundle at the same time results in race conditions
Product:	[RT] Virgo	Reporter:	Alex Blewitt <alex.blewitt>
Component:	unknown	Assignee:	Chris Frost <eclipse>
Status:	CLOSED FIXED	QA Contact:
Severity:	minor
Priority:	P3	CC:	eclipse, glyn.normington
Version:	3.0.0.M01
Target Milestone:	3.0.0.M04
Hardware:	PC
OS:	All
Whiteboard:

Description Alex Blewitt

2011-02-22 10:19:56 EST

Given an automated build that:

* Generates a PAR (Say, Foo.par), and
* Generates a Plan (Say, Foo.plan), and
* Installs the PAR into the repository (-> repository/usr/Foo.par), and
* Installs the Plan into pickup (->pickup/Foo.plan)

then the installation of Foo.plan fails because Par wasn't present prior to the plan being installed.

I imagine (but I don't know) that the usr/repository is scanned at startup, so any combined installation like this (the first time) will fail. A subsequent restart will fix the problem.

Can the repository be re-scanned when a new plan is installed, prior to complaining that the bundles don't exist? If there are new or updated contents in the repository, perhaps sync'ing the repository contents before executing the plan would make sense.

Comment 1 Glyn Normington

2011-02-22 10:32:15 EST

repository/usr is a watched directory and so it is scanned at start-up and periodically thereafter. The period between scans defaults to 5 seconds and can be configured using the property repository-name.watchInterval described in the user guide.

So perhaps a workaround would be to set the period to 1 second and have the automated build pause for a little over 1 second before installing the plan.

I don't suppose this will help, but please note there is a mxbean for repository/usr with a forceCheck operation to force a scan. If the automated build could drive the mbean, that would be a better workaround.

Comment 2 Alex Blewitt

2011-02-22 12:26:03 EST

The build is generated by a copy mechanism, and it copies all files over (which are in a repository/usr and pickup/ structure already) so it's the same copy mechanism. Granted, this could be worked around by doing it in 2 copy operations or by tickling the mbean, but it would be nicer if it Just Worked (TM).

If the usr/ repository is periodically re-scanned anyway, and you know when a file has been picked up in the 'pickup', you could schedule a usr/repository rescan ahead of executing the pick'd up code. It would be a little slower, but it would ensure that when dropping in a plan, the state of the system is consistent.

Comment 3 Glyn Normington

2011-02-23 04:13:40 EST

Yes, I'm sure there is a robust solution to this bug. I was simply pointing out some workarounds for the interim.

Comment 4 Alex Blewitt

2011-02-23 05:03:18 EST

(In reply to comment #3)
> Yes, I'm sure there is a robust solution to this bug. I was simply pointing out
> some workarounds for the interim.

Ah, OK. I just used "The Windows Way (tm)" - if it doesn't work first time, run it again. On the second install the plan picks up the artifacts deployed from last time. It's ugly, but it works :-)

Comment 5 Glyn Normington

2011-03-01 07:06:17 EST

Compare https://bugs.eclipse.org/bugs/show_bug.cgi?id=327538#c2 when considering triggering a re-scan of a watched repository.

Comment 6 Chris Frost

2011-03-15 13:02:14 EDT

The RepositoryFactory now published all watched repos in the service registry under the WatchedRepository interface. They are all then obtained and checked before the deployer pipeline is run.

PipelinedApplicationDeployerIntegrationTests have been updated to check for the calls to check watched repositories.