[
https://issues.apache.org/jira/browse/BROOKLYN-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217756#comment-16217756
]
ASF GitHub Bot commented on BROOKLYN-546:
-----------------------------------------
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/867
@ahgittin Still requires some more testing, but wanted to share this now
for feedback.
----
As discussed with @ahgittin, there was an additional rebind issue when
loading the initial catalog (and subsequently loading persisted bundles). Karaf
will have cached OSGi bundles for that initial catalog. The initial catalog
would duplicate some of these - it couldn't tell that the karaf bundle
installed on the previous brooklyn run was identical to the bundle it wanted to
install (it can't yet see the persisted brooklyn-managed records, and it can't
understand osgi location `brooklyn:ID`).
Possible solutions for that included:
1) make `brooklyn:ID` osgi location be a checksum (so the same osgi
location would be used for two identical brooklyn-managed bundles).
2) clear the karaf cache of brooklyn-managed bundles (e.g. all those with
location in the form `brooklyn:ID`), in the knowledge that the initial catalog
and persisted state will reinstall them.
3) load initial catalog _after_ persistence (but we expect the initial
catalog to tell us whether to remove some items from persistence so this isn't
a good option without major re-work).
4) if we're not certain that it's identical, then uninstall and reinstall
the bundle (which is what happens currently). This might be a problem if it's a
core brooklyn module, but those should have `mvn:` urls so it _can_ confirm
whether it's a duplicate).
5) rework rebind / initial catalog load so that we load placeholders for
bundles that have been persisted (enough to do the deduping or install things
referenced in initial catalog load).
We opted for doing (1) and (4).
---
Another issue (FAO @ahgittin) is that every time Brooklyn was started, we'd
add to the persisted state another copy of each core brooklyn bundle!
This is because the initial catalog references things like
`org.apache.brooklyn.policy`. The `ManagedBundle` we create to represent it
gets an auto-generated unique id. We see that the bundle is already installed,
so we don't re-install it in karaf (good). But we do still persist it to the
`/bundles` persisted state sub-directory.
I've worked around that by black-listing `org.apache.brooklyn.*` from being
persisted (see
`OsgiArchiveInstaller.isBlacklistedForPersistence(ManagedBundle)`. The
assumption is that those will always ship with Brooklyn - we should use just
the version that is shipped with the given release of Brooklyn.
---
Another issue (similar, not yet fixed) is that we persist a new identical
copy of `brooklyn-default-karaf-catalog` every time we restart Brooklyn. This
is because the `ManagedBundle` for the initial catalog has an auto-generated
unique id. As above, we do not install the duplicate bundle, but we still
persist it.
Luckily rebind is not as bad as you might think! It spots that an identical
bundle is already installed, so doesn't install it or parse the catalog.bom of
every copy that is in persisted state.
Possible solutions for this include:
1) changing the persistence file/object names to use the
`symbolicName_version.jar` format (similar naming to the old `/catalog`
directory).
2) only persist the bundle if we actually installed it (i.e. it wasn't a
duplicate).
3) search persisted state for a duplicate, and don't add if it already
exists.
Option (1) is very tempting, given that is it's logical unique identity: we
shouldn't be persisting (and thus installing) multiple things with the same
name:version. We'd need to be careful with backwards compatibility if someone
has `/bundles` that uses the unique ids. We could later add additional checks
to only replace the persisted file if its checksum had actually changed.
Option (2) feels wrong - what is persisted depends on what is in your karaf
cache! For example, if you change the persisted state directory then we
wouldn't write out the initial catalog to it because karaf would have cached
those bundles from the previous run.
> On restart fails to install catalog bundles due to existing bundles installed
> with different location
> -----------------------------------------------------------------------------------------------------
>
> Key: BROOKLYN-546
> URL: https://issues.apache.org/jira/browse/BROOKLYN-546
> Project: Brooklyn
> Issue Type: Bug
> Reporter: Duncan Grant
> Priority: Blocker
>
> Rebind will always fail on restart due to errors like the following:
> java.lang.IllegalStateException: Bundle
> BasicManagedBundle{symbolicName=org.apache.brooklyn.software-cm-ansible,
> version=1.0.0.SNAPSHOT,
> url=mvn:org.apache.brooklyn/brooklyn-software-cm-ansible/1.0.0-SNAPSHOT}
> failed installation: BundleException: Bundle symbolic name and version are
> not unique: org.apache.brooklyn.software-cm-ansible:1.0.0.SNAPSHOT
> This seems to have been "caused" by the change:
> https://github.com/apache/brooklyn-server/pull/862/commits/c4f9d95aa2113a1a5022da17768675599e528dd4
> This can be easily tested by starting brooklyn. Stopping brooklyn. And then
> starting brooklyn.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
