[
https://issues.apache.org/jira/browse/BROOKLYN-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15653701#comment-15653701
]
ASF GitHub Bot commented on BROOKLYN-382:
-----------------------------------------
Github user neykov commented on the issue:
https://github.com/apache/brooklyn-server/pull/423
Need to clear the **whole** cache on any addition/removal/update. Specs
will change when transient catalog item dependencies change.
There are things outside of the control of the catalog that a spec depends
on - like non-catalog locations, type registry, adding bundles.
Re-using the specs will cause objects to be shared between applications -
something that could lead to subtle problems (similar to the dsl memberSpeck
locking).
Having said that I believe `BrooklynCatalog.createSpec` is only used by the
REST API so not as bad as it sounds. But better move the logic to the REST API?
The cache will speed up listing, but not adding items or deploying which
could still take considerable time. A much better fix would be to streamline
our catalog parsing logic which currently is way too complicated.
> Catalog takes long time to load in web-console
> ----------------------------------------------
>
> Key: BROOKLYN-382
> URL: https://issues.apache.org/jira/browse/BROOKLYN-382
> Project: Brooklyn
> Issue Type: Improvement
> Affects Versions: 0.9.0
> Reporter: Aled Sage
>
> Using Brooklyn 0.10.0-SNAPSHOT (but also reproducible with 0.9.0)...
> When there are many (yaml) catalog items, the Brooklyn web-console is very
> slow to show the "add application" dialog, or to show a list of the catalog
> items in the catalog view.
> Looking at the REST api timings, the bulk of the time is spent calling
> {{/catalog/entities}} and/or {{/catalog/applications}}.
> A customer with approximately 100 (large) things in their catalog reported
> that it took 15 seconds to show the "add application" dialog. In my testing
> with approx 100 small catalog items, it took approx 5 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
