[jira] [Deleted] (BROOKLYN-631) Vapespring
[ https://issues.apache.org/jira/browse/BROOKLYN-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Heneveld deleted BROOKLYN-631: --- > Vapespring > -- > > Key: BROOKLYN-631 > URL: https://issues.apache.org/jira/browse/BROOKLYN-631 > Project: Brooklyn > Issue Type: New Feature >Reporter: Vape Spring >Priority: Major > > [*VAPESPRING*|https://www.vapespring.com/] > > Vape Spring is a leading online store in collaboration with the Certified > E-liquids manufacturer from Canada. All E-Liquids are USP & FDA Certified and > is produced in an ISO 7 Certified Clean Room. > > > *[Products|https://www.vapespring.com/products] | > [Flavors|https://www.vapespring.com/flavors] | > [NicSalts|https://www.vapespring.com/nic-salts] | > [MixNix|https://www.vapespring.com/mixnix] | > [Shisha|https://www.vapespring.com/shisha] | > [Blog|https://www.vapespring.com/blog] |* > [*Videos*|https://www.vapespring.com/videos] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (BROOKLYN-631) Vapespring
[ https://issues.apache.org/jira/browse/BROOKLYN-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Heneveld closed BROOKLYN-631. -- Resolution: Invalid Bloody spam > Vapespring > -- > > Key: BROOKLYN-631 > URL: https://issues.apache.org/jira/browse/BROOKLYN-631 > Project: Brooklyn > Issue Type: New Feature >Reporter: Vape Spring >Priority: Major > > [*VAPESPRING*|https://www.vapespring.com/] > > Vape Spring is a leading online store in collaboration with the Certified > E-liquids manufacturer from Canada. All E-Liquids are USP & FDA Certified and > is produced in an ISO 7 Certified Clean Room. > > > *[Products|https://www.vapespring.com/products] | > [Flavors|https://www.vapespring.com/flavors] | > [NicSalts|https://www.vapespring.com/nic-salts] | > [MixNix|https://www.vapespring.com/mixnix] | > [Shisha|https://www.vapespring.com/shisha] | > [Blog|https://www.vapespring.com/blog] |* > [*Videos*|https://www.vapespring.com/videos] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (BROOKLYN-606) ATG Stores (client) impression & MUV usage is incorrect
[ https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Heneveld closed BROOKLYN-606. -- Resolution: Invalid > ATG Stores (client) impression & MUV usage is incorrect > --- > > Key: BROOKLYN-606 > URL: https://issues.apache.org/jira/browse/BROOKLYN-606 > Project: Brooklyn > Issue Type: Test >Reporter: Jim Cadigan >Priority: Critical > Attachments: ATG impressions calculator 1.jpg, ATG impressions > calculator 2.jpg > > > I don't know how to log a Jira ticket. I'm the AE on the ATG Stores account > (Lowe's Canada) with Subscription > #[285656357|https://optimizely.lightning.force.com/lightning/r/Subscription__c/a5rC0008SRsIAM/view] > in Salesforce. They are interested in adding more websites which they will > have to upgrade to the Impressions model to do. When we calculate the > Impressions / MUV in ChartIO impressions calculator (go/impressions) it is > estimating the Impressions at 39 million and the MUVs at 6.76 million - which > is way too high according to the CSM. The CSM believes based on the number > of tests they've run it shouldn't be close to that high of amount. Can > someone please look into this further? We have a call to discuss their > options on Tuesday (1/22) so if possible we would like an accurate estimate > by that time (or soon thereafter). Jim Cadigan > [jim.cadi...@optimizely.com|mailto:jim.cadi...@optimizely.com] > > https://chartio.com/optimizelyinc/impressions/?ev459912=285656357=12690680070=12109898642=11925673319=11617832294=11359124158=11081888145=10941983808=10793822095=10673231236=10523345766=10408300039=10200184135 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-606) ATG Stores (client) impression & MUV usage is incorrect
[ https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746533#comment-16746533 ] Alex Heneveld commented on BROOKLYN-606: Thanks, you guys are in the wrong Jira. This is for the Apache Foundation's Brooklyn project. :) > ATG Stores (client) impression & MUV usage is incorrect > --- > > Key: BROOKLYN-606 > URL: https://issues.apache.org/jira/browse/BROOKLYN-606 > Project: Brooklyn > Issue Type: Test >Reporter: Jim Cadigan >Priority: Critical > Attachments: ATG impressions calculator 1.jpg, ATG impressions > calculator 2.jpg > > > I don't know how to log a Jira ticket. I'm the AE on the ATG Stores account > (Lowe's Canada) with Subscription > #[285656357|https://optimizely.lightning.force.com/lightning/r/Subscription__c/a5rC0008SRsIAM/view] > in Salesforce. They are interested in adding more websites which they will > have to upgrade to the Impressions model to do. When we calculate the > Impressions / MUV in ChartIO impressions calculator (go/impressions) it is > estimating the Impressions at 39 million and the MUVs at 6.76 million - which > is way too high according to the CSM. The CSM believes based on the number > of tests they've run it shouldn't be close to that high of amount. Can > someone please look into this further? We have a call to discuss their > options on Tuesday (1/22) so if possible we would like an accurate estimate > by that time (or soon thereafter). Jim Cadigan > [jim.cadi...@optimizely.com|mailto:jim.cadi...@optimizely.com] > > https://chartio.com/optimizelyinc/impressions/?ev459912=285656357=12690680070=12109898642=11925673319=11617832294=11359124158=11081888145=10941983808=10793822095=10673231236=10523345766=10408300039=10200184135 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-606) ATG Stores (client) impression & MUV usage is incorrect
[ https://issues.apache.org/jira/browse/BROOKLYN-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746512#comment-16746512 ] Alex Heneveld commented on BROOKLYN-606: Is this spam or just mis-reported? cc [~infrastruct...@apache.org] Unless anyone can explain how this relates to Apache Brooklyn let's close. > ATG Stores (client) impression & MUV usage is incorrect > --- > > Key: BROOKLYN-606 > URL: https://issues.apache.org/jira/browse/BROOKLYN-606 > Project: Brooklyn > Issue Type: Test >Reporter: Jim Cadigan >Priority: Critical > Attachments: ATG impressions calculator 1.jpg, ATG impressions > calculator 2.jpg > > > I don't know how to log a Jira ticket. I'm the AE on the ATG Stores account > (Lowe's Canada) with Subscription > #[285656357|https://optimizely.lightning.force.com/lightning/r/Subscription__c/a5rC0008SRsIAM/view] > in Salesforce. They are interested in adding more websites which they will > have to upgrade to the Impressions model to do. When we calculate the > Impressions / MUV in ChartIO impressions calculator (go/impressions) it is > estimating the Impressions at 39 million and the MUVs at 6.76 million - which > is way too high according to the CSM. The CSM believes based on the number > of tests they've run it shouldn't be close to that high of amount. Can > someone please look into this further? We have a call to discuss their > options on Tuesday (1/22) so if possible we would like an accurate estimate > by that time (or soon thereafter). Jim Cadigan > [jim.cadi...@optimizely.com|mailto:jim.cadi...@optimizely.com] > > https://chartio.com/optimizelyinc/impressions/?ev459912=285656357=12690680070=12109898642=11925673319=11617832294=11359124158=11081888145=10941983808=10793822095=10673231236=10523345766=10408300039=10200184135 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BROOKLYN-582) AWS EC2 blueprint fails due to invalid instance type proposed
[
https://issues.apache.org/jira/browse/BROOKLYN-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16469692#comment-16469692
]
Alex Heneveld commented on BROOKLYN-582:
Your analysis is correct. This is due to
https://issues.apache.org/jira/browse/JCLOUDS-1379 . A fix to that should fix
this issue.
> AWS EC2 blueprint fails due to invalid instance type proposed
> -
>
> Key: BROOKLYN-582
> URL: https://issues.apache.org/jira/browse/BROOKLYN-582
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Thach Mai
>Priority: Major
>
> When running a blueprint for AWS EC2, specifying "minRam" and "minCores"
> combination will not work for some regions.
> Example of a blueprint that works:
> {{name: WORK}}
> {{services:}}
> {{- type: server}}
> {{ name: WORK}}
> {{location:}}
> {{ jclouds:aws-ec2:}}
> {{ identity: }}
> {{ credential: }}
> {{ }}
> {{ region: eu-west-1}}
> {{ }}
> {{ osFamily: ubuntu}}
> {{ minRam: 4096M}}
> {{ minCores: 4}}
> {{ }}
> {{ user: sample}}
> {{ password: s4mpl3}}
>
> If we run the same blueprint, but changing the region to "eu-west-2", it
> results in an error:
> {\{Error invoking start at EmptySoftwareProcessImpl{id=nd40mzs7n0}: Failed to
> get VM after 2 attempts. - First cause is
> org.jclouds.aws.AWSResponseException: request POST
> [https://ec2.eu-west-2.amazonaws.com/] HTTP/1.1 failed with code 400, error:
> AWSError{requestId='11cc4fed-1a3a-483b-8661-7c1ff68e37ac',
> requestToken='null', code='Unsupported', message='The requested configuration
> is currently not supported. Please check the documentation for supported
> configurations.', context='
> {Response=, Errors=}'} (listed in primary trace); plus 1 more (e.g. the last
> is org.jclouds.aws.AWSResponseException: request POST
> [https://ec2.eu-west-2.amazonaws.com/] HTTP/1.1 failed with code 400, error:
> AWSError\{requestId='ddf4f700-642c-401a-91b0-9e84f39d2208',
> requestToken='null', code='Unsupported', message='The requested configuration
> is currently not supported. Please check the documentation for supported
> configurations.', context='{Response=, Errors=}'}): AWSResponseException:
> request POST [https://ec2.eu-west-2.amazonaws.com/] HTTP/1.1 failed with code
> 400, error: AWSError\{requestId='11cc4fed-1a3a-483b-8661-7c1ff68e37ac',
> requestToken='null', code='Unsupported', message='The requested configuration
> is currently not supported. Please check the documentation for supported
> configurations.', context='{Response=, Errors=}'}}}
>
> The root cause is likely because jClouds algorithm proposes an instance type
> that doesn't exist for some regions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BROOKLYN-579) DNS lookups cached for too long
Alex Heneveld created BROOKLYN-579:
--
Summary: DNS lookups cached for too long
Key: BROOKLYN-579
URL: https://issues.apache.org/jira/browse/BROOKLYN-579
Project: Brooklyn
Issue Type: Bug
Reporter: Alex Heneveld
I've had issues where DNS values are changed but Brooklyn doesn't see those. I
think Java caches hostnames forever by default, ignoring DNS TTL. (Controlling
Route 53 from Brooklyn is one obvious such example!)
We should consider overriding this.
Oracle Cloud describe how
(https://docs.us-phoenix-1.oraclecloud.com/Content/API/SDKDocs/javasdk.htm):
{quote}The JVM uses the
[networkaddress.cache.ttl|http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html]
property to specify the caching policy for DNS name lookups. The value is an
integer that represents the number of seconds to cache the successful lookup.
The default value for many JVMs, {{-1}}, indicates that the lookup should be
cached forever.
Because resources in Oracle Cloud Infrastructure use DNS names that can change,
we recommend that you change the the TTL value to 60 seconds. This ensures that
the new IP address for the resource is returned on next DNS query. You can
change this value globally or specifically for your application:
{quote} *
{quote}To set TTL globally for all applications using the JVM, add the
following in the {{$JAVA_HOME/jre/lib/security/java.security}} file:
{{networkaddress.cache.ttl=60}}{quote}
*
{quote}To set TTL only for your application, set the following in your
application's initialization code:
{{java.security.Security.setProperty("networkaddress.cache.ttl" ,
"60");}}{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BROOKLYN-552) Tomcat entity stop / start fails as entity id changes which update run_dir but tc obviously not moved
[ https://issues.apache.org/jira/browse/BROOKLYN-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245532#comment-16245532 ] Alex Heneveld commented on BROOKLYN-552: almost certain this has been working. why does the `run_dir` sensor change? the entity ID shouldn't change. > Tomcat entity stop / start fails as entity id changes which update run_dir > but tc obviously not moved > - > > Key: BROOKLYN-552 > URL: https://issues.apache.org/jira/browse/BROOKLYN-552 > Project: Brooklyn > Issue Type: Bug >Reporter: Duncan Grant >Priority: Critical > > Reproduce: > Deploy tomcat with: > name: Test Tomcat > location: > centos7_gce_europe > services: > type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer > after entity is running do > br app ent stop > br app ent start > The isrunning check will never pass as the run_dir sensor will have upated > but obviously the directory is not moved on the vm > This is presumably a problem with all blueprints that use the standard pid > check for running??? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BROOKLYN-551) Cannot add location
[
https://issues.apache.org/jira/browse/BROOKLYN-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245528#comment-16245528
]
Alex Heneveld commented on BROOKLYN-551:
[~drigodwin] debug exceptions aren't necessarily a problem so probably
disregard the log as posted. (they can happen eg when it tries to infer the
right structure for the plan. messy, and to be improved, but for now just
ignore in many cases.)
are there any errors/warns? what is the evidence the addition failed?
what you're doing is tested in CatalogYamlLocationTest so this is curious.
> Cannot add location
> ---
>
> Key: BROOKLYN-551
> URL: https://issues.apache.org/jira/browse/BROOKLYN-551
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Duncan Godwin
>
> I cannot add a location either through the add yaml to catalog using:
> {code}
> brooklyn.catalog:
> id: 'my-id'
> name: 'my-name'
> itemType: location
> item:
> type: jclouds:aws-ec2
> brooklyn.config:
> region: eu-central-1
> identity: aaa
> credential:
> {code}
> nor using the location wizard
> I get the following in the logs:
> {code}
> 017-11-09T10:58:33,798 DEBUG 124 o.a.b.c.c.i.CatalogBundleLoader
> [qtp296483222-103] Catalog load, found catalog BOM in 299 some-id
> 0.0.0.SNAPSHOT
> 2017-11-09T10:58:33,799 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] Catalog load, adding catalog item to
> LocalManagementContext[QTViF5xW-z6LjNoy9]: brooklyn.catalog:
> id: some-id
> itemType: location
> item:
> type: jclouds:aws-ec2
> brooklyn.config:
> displayName: some-name
> region: eu-central-1
> identity: aa
> credential: bb
> 2017-11-09T10:58:33,801 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,802 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,802 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] No version specified for catalog item some-id. Using
> default value.
> 2017-11-09T10:58:33,803 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.t.BasicBrooklynTypeRegistry
> [qtp296483222-103] Inserting
> BasicRegisteredType[some-id:0.0.0-SNAPSHOT;some-id:0.0.0-SNAPSHOT] into
> org.apache.brooklyn.core.typereg.BasicBrooklynTypeRegistry@5fe75b4
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] Catalog load, starting validation cycle, 1 to validate
> 2017-11-09T10:58:33,806 DEBUG 124 o.a.b.c.t.AbstractTypePlanTransformer
> [qtp296483222-103] Could not instantiate
> BasicRegisteredType[some-id:0.0.0-SNAPSHOT;some-id:0.0.0-SNAPSHOT]
> (rethrowing):
[jira] [Commented] (BROOKLYN-551) Cannot add location
[
https://issues.apache.org/jira/browse/BROOKLYN-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245527#comment-16245527
]
Alex Heneveld commented on BROOKLYN-551:
[~drigodwin] debug exceptions aren't necessarily a problem so probably
disregard the log as posted. (they can happen eg when it tries to infer the
right structure for the plan. messy, and to be improved, but for now just
ignore in many cases.)
are there any errors/warns? what is the evidence the addition failed?
what you're doing is tested in CatalogYamlLocationTest so this is curious.
> Cannot add location
> ---
>
> Key: BROOKLYN-551
> URL: https://issues.apache.org/jira/browse/BROOKLYN-551
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Duncan Godwin
>
> I cannot add a location either through the add yaml to catalog using:
> {code}
> brooklyn.catalog:
> id: 'my-id'
> name: 'my-name'
> itemType: location
> item:
> type: jclouds:aws-ec2
> brooklyn.config:
> region: eu-central-1
> identity: aaa
> credential:
> {code}
> nor using the location wizard
> I get the following in the logs:
> {code}
> 017-11-09T10:58:33,798 DEBUG 124 o.a.b.c.c.i.CatalogBundleLoader
> [qtp296483222-103] Catalog load, found catalog BOM in 299 some-id
> 0.0.0.SNAPSHOT
> 2017-11-09T10:58:33,799 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] Catalog load, adding catalog item to
> LocalManagementContext[QTViF5xW-z6LjNoy9]: brooklyn.catalog:
> id: some-id
> itemType: location
> item:
> type: jclouds:aws-ec2
> brooklyn.config:
> displayName: some-name
> region: eu-central-1
> identity: aa
> credential: bb
> 2017-11-09T10:58:33,801 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,802 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,802 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] No version specified for catalog item some-id. Using
> default value.
> 2017-11-09T10:58:33,803 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.p.PlanToSpecFactory
> [qtp296483222-103] Plan could not be transformed; failure will be propagated
> (other transformers tried = [Java type instantiator
> (org.apache.brooklyn.core.catalog.internal.JavaCatalogToSpecTransformer
> parses only old-style catalog items containing only 'type: JavaClass' or
> javaType in DTO)]): [org.apa
> che.brooklyn.util.exceptions.PropagatedRuntimeException: Transformer for
> Brooklyn OASIS CAMP interpreter gave an error creating this plan: No class or
> resolver found for location type jclouds:aws-ec2]
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.t.BasicBrooklynTypeRegistry
> [qtp296483222-103] Inserting
> BasicRegisteredType[some-id:0.0.0-SNAPSHOT;some-id:0.0.0-SNAPSHOT] into
> org.apache.brooklyn.core.typereg.BasicBrooklynTypeRegistry@5fe75b4
> 2017-11-09T10:58:33,805 DEBUG 124 o.a.b.c.c.i.BasicBrooklynCatalog
> [qtp296483222-103] Catalog load, starting validation cycle, 1 to validate
> 2017-11-09T10:58:33,806 DEBUG 124 o.a.b.c.t.AbstractTypePlanTransformer
> [qtp296483222-103] Could not instantiate
> BasicRegisteredType[some-id:0.0.0-SNAPSHOT;some-id:0.0.0-SNAPSHOT]
> (rethrowing):
[jira] [Commented] (BROOKLYN-539) ClassCastExceptions on rebind (trying to persist catalog items)
[
https://issues.apache.org/jira/browse/BROOKLYN-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176335#comment-16176335
]
Alex Heneveld commented on BROOKLYN-539:
Correct, there is no need to persist types that come from bundles. Persistence
of catalog is only needed for legacy items.
Curious why it is (now) trying to persist this (and others).
> ClassCastExceptions on rebind (trying to persist catalog items)
> ---
>
> Key: BROOKLYN-539
> URL: https://issues.apache.org/jira/browse/BROOKLYN-539
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> With bleeding edge 0.12.0-SNAPSHOT, I started Brooklyn (in Karaf mode), then
> stopped it and restarted it again.
> On rebind, I see exceptions like that below many times in the info log. I
> think it's logged once per item in the catalog.
> {noformat}
> 2017-09-20T11:42:36,406 WARN 122 o.a.b.c.m.r.PersistenceExceptionHandlerImpl
> [FelixStartLevel] Problem persisting (ignoring): generate memento for
> CATALOG_ITEM
> org.apache.brooklyn.core.typereg.RegisteredTypes$CatalogItemFromRegisteredType
> (pr-128-top-level:1.0.0)
> java.lang.ClassCastException:
> org.apache.brooklyn.core.typereg.RegisteredTypes$CatalogItemFromRegisteredType
> cannot be cast to org.apache.brooklyn.core.objs.BrooklynObjectInternal
> at
> org.apache.brooklyn.core.mgmt.rebind.PeriodicDeltaChangeListener.persistNowInternal(PeriodicDeltaChangeListener.java:454)
> [122:org.apache.brooklyn.core:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.core.mgmt.rebind.PeriodicDeltaChangeListener.persistNowSafely(PeriodicDeltaChangeListener.java:379)
> [122:org.apache.brooklyn.core:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.core.mgmt.rebind.PeriodicDeltaChangeListener.persistNowSafely(PeriodicDeltaChangeListener.java:373)
> [122:org.apache.brooklyn.core:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl.forcePersistNow(RebindManagerImpl.java:476)
> [122:org.apache.brooklyn.core:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.launcher.common.BasicLauncher.persist(BasicLauncher.java:434)
> [126:org.apache.brooklyn.launcher-common:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.launcher.common.BasicLauncher.startPartTwo(BasicLauncher.java:426)
> [126:org.apache.brooklyn.launcher-common:0.12.0.SNAPSHOT]
> at
> org.apache.brooklyn.launcher.osgi.OsgiLauncherImpl.startOsgi(OsgiLauncherImpl.java:116)
> [333:org.apache.brooklyn.karaf-init:0.12.0.SNAPSHOT]
> at Proxy5b14e94c_cf63_4a4e_a22b_a2fdda9c9134.startOsgi(Unknown
> Source) [?:?]
> at
> org.apache.brooklyn.launcher.osgi.start.OsgiLauncherCompleter.init(OsgiLauncherCompleter.java:36)
> [335:org.apache.brooklyn.karaf-start:0.12.0.SNAPSHOT]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:736)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
> [15:org.apache.aries.blueprint.core:1.8.2]
> at
>
[jira] [Resolved] (BROOKLYN-343) Cross-referencing catalog items fails
[ https://issues.apache.org/jira/browse/BROOKLYN-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Heneveld resolved BROOKLYN-343. Resolution: Fixed Assignee: Alex Heneveld Fix Version/s: 0.12.0 Fixed by PR 746 > Cross-referencing catalog items fails > - > > Key: BROOKLYN-343 > URL: https://issues.apache.org/jira/browse/BROOKLYN-343 > Project: Brooklyn > Issue Type: Bug >Reporter: Svetoslav Neykov >Assignee: Alex Heneveld > Fix For: 0.12.0 > > > The camp parser doesn't see items which are in the same catalog and already > parsed. Only already added items are visible. The catalog parsers does a > poor-man's validation on the top level items only, we need to replace that > with the normal CAMP parser workflow, but able to see items in the current > catalog preceding the current item. > On the other hand removing services works just fine. > See the failing test case in > https://github.com/apache/brooklyn-server/pull/125 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BROOKLYN-498) Deadlock in MembershipTrackingPolicyTest when updating sensors vs group members
[
https://issues.apache.org/jira/browse/BROOKLYN-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998301#comment-15998301
]
Alex Heneveld commented on BROOKLYN-498:
Thread 1 is trying to publish to members (needing members list lock while
holding the AttributeMap.values lock).
Main is updating the GROUP_MEMBERS sensor (needing AM.values lock) while adding
a child member (holding members list lock).
We have a similar issue with addition/removal of children -- in
AbstractEntity.addChild we've taken the view to publish outwith holding the
lock which as a comment there notes could mean that we publish REMOVED _after_
publishing ADDED. We could take the same approach to group members. However
it is nice being able to rely on publishing order.
The other option is to mandate that if the values lock is going to be sought
while holding members or children, the values lock should be taken first. This
feels safer to me. [~aledsage] ?
> Deadlock in MembershipTrackingPolicyTest when updating sensors vs group
> members
> ---
>
> Key: BROOKLYN-498
> URL: https://issues.apache.org/jira/browse/BROOKLYN-498
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Core tests can hang due to this. Set high invocation count eg on
> {{testDeprecatedSetGroupWorks}} to expose.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (BROOKLYN-498) Deadlock in MembershipTrackingPolicyTest when updating sensors vs group members
[
https://issues.apache.org/jira/browse/BROOKLYN-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998245#comment-15998245
]
Alex Heneveld commented on BROOKLYN-498:
{noformat}
Found one Java-level deadlock:
=
"brooklyn-execmanager-FxWzkzWW-2":
waiting to lock monitor 0x7fa164b42bd8 (object 0x0007b864e618, a
java.util.Collections$SynchronizedMap),
which is held by "brooklyn-execmanager-FxWzkzWW-1"
"brooklyn-execmanager-FxWzkzWW-1":
waiting to lock monitor 0x7fa164b441d8 (object 0x0007b8661c60, a
java.util.LinkedHashSet),
which is held by "main"
"main":
waiting to lock monitor 0x7fa164b42bd8 (object 0x0007b864e618, a
java.util.Collections$SynchronizedMap),
which is held by "brooklyn-execmanager-FxWzkzWW-1"
Java stack information for the threads listed above:
===
"brooklyn-execmanager-FxWzkzWW-2":
at java.util.Collections$SynchronizedMap.get(Collections.java:2584)
- waiting to lock <0x0007b864e618> (a
java.util.Collections$SynchronizedMap)
at
org.apache.brooklyn.core.sensor.AttributeMap.getValue(AttributeMap.java:200)
at
org.apache.brooklyn.core.sensor.AttributeMap.getValue(AttributeMap.java:206)
at
org.apache.brooklyn.core.entity.AbstractEntity$BasicSensorSupport.get(AbstractEntity.java:1086)
at
org.apache.brooklyn.core.entity.AbstractEntity.getAttribute(AbstractEntity.java:993)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.brooklyn.core.objs.proxy.EntityProxyImpl.invoke(EntityProxyImpl.java:189)
at com.sun.proxy.$Proxy196.getAttribute(Unknown Source)
at
org.apache.brooklyn.core.entity.lifecycle.ServiceStateLogic$ComputeServiceIndicatorsFromChildrenAndMembers.computeServiceNotUp(ServiceStateLogic.java:563)
at
org.apache.brooklyn.core.entity.lifecycle.ServiceStateLogic$ComputeServiceIndicatorsFromChildrenAndMembers.onUpdated(ServiceStateLogic.java:548)
at
org.apache.brooklyn.enricher.stock.AbstractMultipleSensorAggregator.onEvent(AbstractMultipleSensorAggregator.java:137)
at
org.apache.brooklyn.core.mgmt.internal.LocalSubscriptionManager$1.run(LocalSubscriptionManager.java:276)
at
org.apache.brooklyn.util.concurrent.CallableFromRunnable.call(CallableFromRunnable.java:44)
at
org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:529)
at
org.apache.brooklyn.util.core.task.SingleThreadedScheduler$1.call(SingleThreadedScheduler.java:116)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
"brooklyn-execmanager-FxWzkzWW-1":
at
org.apache.brooklyn.entity.group.AbstractGroupImpl.getMembers(AbstractGroupImpl.java:269)
- waiting to lock <0x0007b8661c60> (a java.util.LinkedHashSet)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.brooklyn.core.objs.proxy.EntityProxyImpl.invoke(EntityProxyImpl.java:189)
at com.sun.proxy.$Proxy196.getMembers(Unknown Source)
at
org.apache.brooklyn.core.mgmt.internal.AbstractSubscriptionManager$2.apply(AbstractSubscriptionManager.java:139)
at
org.apache.brooklyn.core.mgmt.internal.AbstractSubscriptionManager$2.apply(AbstractSubscriptionManager.java:1)
at
org.apache.brooklyn.core.mgmt.internal.LocalSubscriptionManager.submitPublishEvent(LocalSubscriptionManager.java:225)
at
org.apache.brooklyn.core.mgmt.internal.LocalSubscriptionManager.publish(LocalSubscriptionManager.java:216)
at
org.apache.brooklyn.core.mgmt.internal.BasicSubscriptionContext.publish(BasicSubscriptionContext.java:176)
at
org.apache.brooklyn.core.entity.AbstractEntity$BasicSensorSupport.emitInternal(AbstractEntity.java:1213)
at
org.apache.brooklyn.core.entity.AbstractEntity.emitInternal(AbstractEntity.java:1993)
at
org.apache.brooklyn.core.sensor.AttributeMap.update(AttributeMap.java:133)
at
org.apache.brooklyn.core.sensor.AttributeMap.modify(AttributeMap.java:162)
- locked <0x0007b864e618> (a java.util.Collections$SynchronizedMap)
at
org.apache.brooklyn.core.entity.AbstractEntity$BasicSensorSupport.modify(AbstractEntity.java:1154)
at
[jira] [Created] (BROOKLYN-498) Deadlock in MembershipTrackingPolicyTest when updating sensors vs group members
Alex Heneveld created BROOKLYN-498:
--
Summary: Deadlock in MembershipTrackingPolicyTest when updating
sensors vs group members
Key: BROOKLYN-498
URL: https://issues.apache.org/jira/browse/BROOKLYN-498
Project: Brooklyn
Issue Type: Bug
Reporter: Alex Heneveld
Core tests can hang due to this. Set high invocation count eg on
{{testDeprecatedSetGroupWorks}} to expose.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (BROOKLYN-492) Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
[
https://issues.apache.org/jira/browse/BROOKLYN-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993947#comment-15993947
]
Alex Heneveld commented on BROOKLYN-492:
The hack workaround suggestion was to have two files claiming identical
versions but with different ranges on the Import-Package so that only the right
one can be resolved, avoiding indeterminacy. But you are correct Karaf doesn't
let you have two installed bundles with the same name+version so that's out.
But maybe that idea will work with an extra dependency?
Let's say the problem is this:
* Author has a bundle {{my_java:1.0}} which depends on {{brooklyn}} version
0.11, and a catalog item {{foo}} which requires code in {{my_java}} in package
{{org.my_java}}, and this catalog item is declared in a catalog BOM depending
on library {{http:://artifactory/path/to/my_java_1.0.jar}}
* User has deployed an instance of {{foo}} to a brooklyn 0.11 server
* Operator wants to update the brooklyn server to 0.12 -- but {{my_java:1.0}}
doesn't work with 0.12, that bundle won't install, and as a result {{foo}}
fails to rebind (or possibly fails after rebind)
Could a manual workaround be as follows:
# Author creates a new bundle {{my_java_real:1.0}} containing the java
currently in {{my_java}}, and ensures that bundle depends on
{{brooklyn:[0.11,0.12)}} (e.g. through an imports-package statement)
# Author creates an upgrade to that bundle in {{my_java_real:1.1}} which
depends on (and is compatible with) {{brooklyn:[0.12,0.13)}}
# Author creates a new {{my_java}} which {{Import-Package: org.my_java}} (any
version) and exports the same package
# Author installs this new {{my_java}} at the URL referenced in the BOM --
masking it
# Operator installs both {{my_java_real:1.0}} and {{my_java_real:1.1}} into
their brooklyn container and uninstalls any existing (old) {{my_java}} -- which
version of the brooklyn container doesn't matter and of course one of the
{{my_java_real}} versions won't be resolvable but that's going to be okay
# Operator now rebinds to existing state (possibly a rebind was attempted
previously and failed, but at least it provided an opportunity to install the
{{my_java_real}} bundles into their container; this should pull down the new
{{my_java}} which will then resolve the correct {{my_java_real}}
It's a bit tedious, it means manually installing dependency bundles, and
swapping the {{my_java}} URL is ugly but:
* This gives a technique that works with either Brooklyn version
* It doesn't require the *user* to do anything
* It doesn't require doing anything to persisted state
For a v2 of {{foo}} I'd say to put {{foo}} and the BOM into in an OSGi bundle
which declares a {{MANIFEST.MF}} dependency to {{Import-Package: org.my_java}};
this removes the need for the intermediate {{my_java}} bundle and means
Brooklyn doesn't have to track any dependencies and versions, plus it means we
don't need to update {{foo}} on a Brooklyn version change. This doesn't solve
the problem that we need the appropriate {{my_java_real}} bundle installed, but
there are quite a few options -- simplest is to say to install it into the old
version of Brooklyn, and give an option not to start it (or by default don't
start if there is no {{catalog.bom}} contained inside) -- though in any case it
feels like we could live without that.
There will be times when we _do_ need to update {{foo}} on a Brooklyn version
change. Ideally there should be a {{foo}} that works with multiple Brooklyn
versions so we can install new {{foo}} into old-version Brooklyn instance, then
we have a way to mark old {{foo}} as deprecated, then upgrade all old {{foo}}
instances, then start new Brooklyn version. But we should think through the
case when {{foo}} _can't_ work with multiple Brooklyn versions; eg {{foo:2}}
works with {{brooklyn:0.12}} and {{foo:3}} with {{brooklyn:0.13}}. One
technique could be to install {{foo:3}} into the {{brooklyn:0.12}} container
but with some sort of "optional" flag so it doesn't complain if it can't
resolve. We then have a boot-time (or pre-rebind) way when starting
{{brooklyn:0.13}} to say: "mark {{foo:2}} optional and deprecated, and mark
{{foo:3}} not optional, and upgrade all deprecated things".
I still think the proposal and leaning more on OSGi largely solves things. I
definitely prefer that over copy-state transformations!
> Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
> -
>
> Key: BROOKLYN-492
> URL: https://issues.apache.org/jira/browse/BROOKLYN-492
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> When a user refers to their custom OSGi bundle in a catalog's
> {{brooklyn.libraries}} section, this could make subsequent upgrade of
>
[jira] [Commented] (BROOKLYN-334) "brooklyn" banner on the console should be "apache brooklyn"
[
https://issues.apache.org/jira/browse/BROOKLYN-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992646#comment-15992646
]
Alex Heneveld commented on BROOKLYN-334:
As hinted in the PR [1] I think we should close this with no action. The
attempts to put "Apache Brooklyn" as a banner are ugly, and there is precedent:
Karaf itself shows a banner simply saying "Karaf", with "Apache Karaf" beneath
- see [2].
[1] https://github.com/apache/brooklyn-server/pull/657
[2] https://karaf.apache.org/manual/latest/
> "brooklyn" banner on the console should be "apache brooklyn"
>
>
> Key: BROOKLYN-334
> URL: https://issues.apache.org/jira/browse/BROOKLYN-334
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.10.0
>Reporter: Richard Downer
>
> When starting Brooklyn (either the standalone assembly, or the Brooklyn-Karaf
> distribution), you see this:
> {noformat}
> _ __
> | |__ _ __ ___ ___ | | _| |_ _ _ __ (R)
> | '_ \| '__/ _ \ / _ \| |/ / | | | | '_ \
> | |_) | | | (_) | (_) | <| | |_| | | | |
> |_.__/|_| \___/ \___/|_|\_\_|\__, |_| |_|
>|___/
> {noformat}
> This needs to say "Apache Brooklyn" (presumably still stylised in all
> lower-case)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (BROOKLYN-492) Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
[
https://issues.apache.org/jira/browse/BROOKLYN-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983730#comment-15983730
]
Alex Heneveld commented on BROOKLYN-492:
Would being able to trigger upgrades on startup/rebind not solve this? IE tell
Brooklyn to upgrade all instances of the catalog item before instantiating,
thus pulling in the 0.12.0-compatible custom java bundles? That's what I was
thinking in my proposal -- though it might need to be made explicit and there's
a fair bit of work to get there.
As an immediate hack/fix does OSGi allow you to provide two bundles at the same
version with different upstream dependent versions? This is an abuse of
versions but if you install two variants of the custom bundle with the same
version but different dependencies, and we could rely on OSGi to eliminate
bundles that aren't compatible, that would solve the problem.
The proposal also calls for version ranges. Going forward I think open-ended
version ranges e.g. "[1.1.0,1.2)" gives a nice way to be able to supply an
upgraded java bundle without cheating versions and without having to force
upgrades of catalog items. (The ranges could be in brooklyn.libraries or we
could deprecate that and just piggy-back on a MANIFEST.MF.)
> Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
> -
>
> Key: BROOKLYN-492
> URL: https://issues.apache.org/jira/browse/BROOKLYN-492
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> When a user refers to their custom OSGi bundle in a catalog's
> {{brooklyn.libraries}} section, this could make subsequent upgrade of
> Brooklyn more difficult.
> This is separate from Alex's email thread to dev@brooklyn "Making blueprint
> upgrades easier - feature proposal" (i.e. it would not be solved by Alex's
> proposal). However, it's worth thinking about that as well for a long-term
> holistic solution.
> ---
> Consider the following steps:
> * With Brooklyn 0.11.0:
> * A user writes a custom OSGi bundle (e.g. containing their own custom
> policy or Java entity or whatever), compiled against Brooklyn 0.11.0.
> * The user creates a catalog item (v1.0), which references that bundle.
> * The user deploys some apps that use this catalog item (with their state
> being persisted).
> * When Brooklyn 0.12.0 comes out, the user attempts to upgrade:
> * The user tries to start 0.12.0, rebinding against their existing
> persisted state. This reads the catalog, and thus attempts to install/active
> the user's custom OSGi bundle.
> * Their custom bundle may fail to install (e.g. perhaps there are wiring
> errors due to dependency changes between 0.11.0 and 0.12.0);
> or alternatively perhaps the bundle loads, but the instances of the Java
> policy/entity fail to be instantiated (e.g. 0.11.0 and 0.12.0 are not binary
> compatible, with the user's code relying on some class/method that has
> changed).
> * Rebind therefore might fails.
> * The user tries to update their custom OSGi bundle:
> * The user updates their code and recompiles, to create a v2.0 of their
> bundle and of their catalog item.
> * However, they can't start 0.12.0 with the existing persisted state in
> order to add the v2.0 catalog item, and upgrade their entities.
> * The user might then try starting 0.11.0 up instead, and adding v2.0 of
> the catalog item there.
> This might work, or it might lead to bundle wiring errors because v2.0 is
> incompatible with Brooklyn 0.11.0.
> How likely this is to actually impact a user depends on: 1) what binary
> incompatible changes we might make in Brooklyn between versions; and 2) what
> parts of Brooklyn the user's Java code makes use of. Some power-users do some
> pretty sophisticated things, digging into the less frequented classes of
> Brooklyn that on first blush might not be considered part of our "api"!
> ---
> The long-term solution needs a lot more discussion on the dev@brooklyn
> mailing list.
> However, it might well revolve around being able to start Brooklyn into a
> usable state, even when some blueprints/entities have errors. This is
> important so that errors can be resolved, and so that errors in some
> blueprints don't cause the entire server to become unusable.
> This is particularly important for big companies using Brooklyn, where there
> is a separation of teams: one team responsible for managing Brooklyn
> servers/upgrades, and other teams responsible for writing blueprints /
> catalog items.
> ---
> A short-term solution could involve using offline tools to transform the
> persisted state (e.g. using something like {{bin/brooklyn copy-state ...
> --transformations ...}}).
> Note that the {{copy-state}} commands are not readily available if one is
>
[jira] [Commented] (BROOKLYN-445) Search path and meaning of catalogItemId is overloaded
[ https://issues.apache.org/jira/browse/BROOKLYN-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887951#comment-15887951 ] Alex Heneveld commented on BROOKLYN-445: A simple fix is to prevent the call to set the catalog item ID from a context thread. All tests seem to pass - see https://github.com/apache/brooklyn-server/pull/573 . If this is problematic we will have to introduce a separate "searchable catalog item IDs" field, or, probably better, introduce and use `catalogItemIdsForSearching` which could be a list, including caller context. (This may be related to an idea for a `catalogBomId` on catalog items, so we know which BOM defines things, and can resolve unversioned references to the same BOM where an item is defined, so e.g. if my-cluster:1.0 refers to my-node, with my-cluster and my-node in the same bundle/bom, then my-node is resolved to the local bom as my-cluster, rather than the latest my-node.) > Search path and meaning of catalogItemId is overloaded > -- > > Key: BROOKLYN-445 > URL: https://issues.apache.org/jira/browse/BROOKLYN-445 > Project: Brooklyn > Issue Type: Bug >Affects Versions: 0.10.0 >Reporter: Alex Heneveld > > We use catalogItemId on a spec or BrooklynObject for two things: > (1) Record the catalog item that was defined to create an item > (2) Find the search path to use when looking up resources and/or creating > other specs > Most of the time these two are the same, e.g. an entity comes from catalog > item `cassandra-node:1.0` and the implementation should use the bundles > defined against that to resolve scripts etc. The catalogItemId is the only > record of the catalog-entry that was used to define the entity; the entity > spec reduces it to the java type which might tell you one bundle but won't > tell you of other library entries from the definition. > However in some cases we seem to want the context catalogItemId to be > inherited, e.g. we reference a stock type like `VanillaServer` as a child but > supply config pointing at scripts/images in the parent's bundle. This is > currently achieved by a line in AbstractBrooklynObjectSpec's constructor > which sets the catalogItemId from the thread context entity's catalog item > ID. However there are a couple problems with this: > (A) We can't tell if the `catalogItemId` is the definition of an entity (it > usually is, but sometimes might be inherited), so we can't tell what was used > to create an entity > (B) A child's search behaviour differs depending whether that child comes > from another catalogItemId (which will overwrite the inherited context > catalogItemId) or a stock item (e.g. a java type is passed to the spec > constructor) > (C) When setting the EntityDynamicType we can't tell whether to clear the > config keys set there; in InternalEntityFactory.addSpecParameters we need to > know whether the spec extends the Java type defining it (in which case CAMP > code in BasicSpecParameter.initializeSpecWithExplicitParameters has filtered > out those keys which are not type-definition inheritable and set the > spec.parameters, so the EntityDynamicType's keys should be cleared) or not > (in which case spec.parameters won't normally be set and EDT.configKeys > should not be cleared). Currently it checks whether there is a > catalogItemId, and assume it is set iff the spec is extending (former case); > this assumption fails if catalogItemId is inherited from context. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (BROOKLYN-445) Search path and meaning of catalogItemId is overloaded
Alex Heneveld created BROOKLYN-445: -- Summary: Search path and meaning of catalogItemId is overloaded Key: BROOKLYN-445 URL: https://issues.apache.org/jira/browse/BROOKLYN-445 Project: Brooklyn Issue Type: Bug Affects Versions: 0.10.0 Reporter: Alex Heneveld We use catalogItemId on a spec or BrooklynObject for two things: (1) Record the catalog item that was defined to create an item (2) Find the search path to use when looking up resources and/or creating other specs Most of the time these two are the same, e.g. an entity comes from catalog item `cassandra-node:1.0` and the implementation should use the bundles defined against that to resolve scripts etc. The catalogItemId is the only record of the catalog-entry that was used to define the entity; the entity spec reduces it to the java type which might tell you one bundle but won't tell you of other library entries from the definition. However in some cases we seem to want the context catalogItemId to be inherited, e.g. we reference a stock type like `VanillaServer` as a child but supply config pointing at scripts/images in the parent's bundle. This is currently achieved by a line in AbstractBrooklynObjectSpec's constructor which sets the catalogItemId from the thread context entity's catalog item ID. However there are a couple problems with this: (A) We can't tell if the `catalogItemId` is the definition of an entity (it usually is, but sometimes might be inherited), so we can't tell what was used to create an entity (B) A child's search behaviour differs depending whether that child comes from another catalogItemId (which will overwrite the inherited context catalogItemId) or a stock item (e.g. a java type is passed to the spec constructor) (C) When setting the EntityDynamicType we can't tell whether to clear the config keys set there; in InternalEntityFactory.addSpecParameters we need to know whether the spec extends the Java type defining it (in which case CAMP code in BasicSpecParameter.initializeSpecWithExplicitParameters has filtered out those keys which are not type-definition inheritable and set the spec.parameters, so the EntityDynamicType's keys should be cleared) or not (in which case spec.parameters won't normally be set and EDT.configKeys should not be cleared). Currently it checks whether there is a catalogItemId, and assume it is set iff the spec is extending (former case); this assumption fails if catalogItemId is inherited from context. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (BROOKLYN-272) Non-deterministic test failures in jenkins
[
https://issues.apache.org/jira/browse/BROOKLYN-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874847#comment-15874847
]
Alex Heneveld commented on BROOKLYN-272:
Many of the immediate-related timeout tests have been fixed to be deterministic
and re-enabled, in https://github.com/apache/brooklyn-server/pull/565
> Non-deterministic test failures in jenkins
> --
>
> Key: BROOKLYN-272
> URL: https://issues.apache.org/jira/browse/BROOKLYN-272
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> There are several non-deterministic tests that fail occasionally in the
> apache jenkins build. We should fix those tests: either the underlying bug if
> there is one, or the way to the test has been written to make it more
> deterministic.
> Having build failures unrelated to the changes being made in a PR (and on
> master) is extremely disruptive for development. We must avoid that wherever
> possible.
> I therefore suggest we disable these non-deterministic failing tests
> immediately, and use this jira issue to track fixing them. We can annotate
> the tests with
> {noformat}
> @Test(groups={"WIP", "Non-deterministic-failure"})
> {noformat}
> to make them easy to find. (note the "Non-deterministic-failure" group is
> not used by any profiles, it's just there for searching purposes).
> The tests I have identified from recent build failures are:
> * {{BasicStartableTest.testTransitionsThroughLifecycles}} - see
> https://issues.apache.org/jira/browse/BROOKLYN-256
> * {{AbstractGeoDnsServiceTest.testFiltersForRunningEntities}}, failing with:
> {noformat}
> org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
> succeeds-eventually, 69 attempts, 30003ms elapsed: AssertionError:
> val={R48yHLqg=, eBHFc4Qd=}
> at org.apache.brooklyn.test.Asserts.fail(Asserts.java:721)
> at org.apache.brooklyn.test.Asserts.assertTrue(Asserts.java:703)
> at
> org.apache.brooklyn.core.entity.EntityAsserts$2.run(EntityAsserts.java:92)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1277)
> at
> org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:930)
> at
> org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:854)
> at
> org.apache.brooklyn.core.entity.EntityAsserts.assertAttributeEventually(EntityAsserts.java:89)
> at
> org.apache.brooklyn.core.entity.EntityAsserts.assertAttributeEventually(EntityAsserts.java:84)
> at
> org.apache.brooklyn.entity.dns.AbstractGeoDnsServiceTest.testFiltersForRunningEntities(AbstractGeoDnsServiceTest.java:263)
> {noformat}
> * {{LoadBalancingPolicyConcurrencyTest.testConcurrentlyAddContainers}},
> failing with:
> {noformat}
> org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
> succeeds-eventually, 29 attempts, 10002ms elapsed: AssertionError:
> actual=[18.0, 21.0, 19.0, 0.0, 20.0, 0.0, 20.0, 36.0, 19.0, 0.0, 19.0, 21.0,
> 21.0, 19.0, 21.0, 36.0, 21.0, 19.0, 18.0, 36.0]; expected=[20.0, 20.0, 20.0,
> 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0,
> 20.0, 20.0, 20.0, 20.0] expected [20.0] but found [0.0]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:207)
> at
> org.apache.brooklyn.policy.loadbalancing.AbstractLoadBalancingPolicyTest.assertWorkrates(AbstractLoadBalancingPolicyTest.java:122)
> at
> org.apache.brooklyn.policy.loadbalancing.AbstractLoadBalancingPolicyTest$2.run(AbstractLoadBalancingPolicyTest.java:138)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1277)
> at
> org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:930)
> at
> org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:854)
> at
> org.apache.brooklyn.policy.loadbalancing.AbstractLoadBalancingPolicyTest.assertWorkratesEventually(AbstractLoadBalancingPolicyTest.java:136)
> at
> org.apache.brooklyn.policy.loadbalancing.LoadBalancingPolicyConcurrencyTest.testConcurrentlyAddContainers(LoadBalancingPolicyConcurrencyTest.java:101)
> {noformat}
> * {{PollerTest.testFeedContinuesWhenPollerThrows}}, failing with:
> {noformat}
>
> testFeedContinuesWhenPollerThrows(org.apache.brooklyn.core.feed.PollerTest)
> Time elapsed: 3.556 sec <<< FAILURE!
> org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
> succeeds-eventually, 4 attempts, 105ms elapsed: AssertionError:
> entity=FeedExceptionEntityImpl{id=dYG0SKbP}; attribute=Sensor: flag
> (java.lang.Boolean) expected [false] but found [true]
> at
[jira] [Commented] (BROOKLYN-329) $brooklyn:config hangs, rather than getting default brooklyn.parameter value
[
https://issues.apache.org/jira/browse/BROOKLYN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15735236#comment-15735236
]
Alex Heneveld commented on BROOKLYN-329:
hard to read GitHub's posts so to summarise
#462 fixes items (1), (5), and (6) above
#480 fixes (2) and (3+4)
immediate evaluation continues not to require new threads except in a few cases
(and notes on eliminating/improving that have been added)
believe this issue can be closed when those PR's are merged
> $brooklyn:config hangs, rather than getting default brooklyn.parameter value
>
>
> Key: BROOKLYN-329
> URL: https://issues.apache.org/jira/browse/BROOKLYN-329
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>Priority: Minor
>
> Using 0.10.0-SNAPSHOT...
> I wrote a YAML entity where CouchDB was configured with an initial
> username/password, and another app that included CouchDB would inject it.
> In each blueprint, I defined a brooklyn.parameter with a default value for
> the username/password. I used the same config key name in each.
> However, when I ran my blueprint it hung. The CouchDB was waiting forever for
> the username/password config value.
> I recreated this behaviour in the simpler test case below (which I'll add to
> {{ConfigParametersYamlTest}}).
> The workaround is to use a different name for the config key in each
> blueprint. For example, in the outer blueprint above if youchange the name to
> {{my.param.key2}} then the test passes.
> Debugging it, one surprising thing I noticed is that {{scopeRoot()}}
> evaluates to be "entity-with-tests" rather than {{wrapper-entity}}.
> {noformat}
> public void testConfigParameterPassedFromOuterConfigParameter() throws
> Exception {
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: entity-with-keys",
> "item:",
> " type: "+TestEntity.class.getName(),
> " brooklyn.parameters:",
> " - name: my.param.key",
> "type: string",
> "default: myDefaultVal",
> " brooklyn.config:",
> "my.other.key: $brooklyn:config(\"my.param.key\")");
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: wrapper-entity",
> "item:",
> " brooklyn.parameters:",
> " - name: my.param.key",
> "type: string",
> "default: myDefaultValInOuter",
> " type: entity-with-keys",
> " brooklyn.config:",
> "my.param.key:
> $brooklyn:scopeRoot().config(\"my.param.key\")");
>
> String yaml = Joiner.on("\n").join(
> "services:",
> "- type: wrapper-entity");
>
> Entity app = createStartWaitAndLogApplication(yaml);
> final TestEntity entity = (TestEntity)
> Iterables.getOnlyElement(app.getChildren());
> Asserts.assertReturnsEventually(new Runnable() {
> public void run() {
>
> assertEquals(entity.config().get(ConfigKeys.newStringConfigKey("my.other.key")),
> "myDefaultValInOuter");
> }},
> Asserts.DEFAULT_LONG_TIMEOUT);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-329) $brooklyn:config hangs, rather than getting default brooklyn.parameter value
[
https://issues.apache.org/jira/browse/BROOKLYN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15715229#comment-15715229
]
Alex Heneveld commented on BROOKLYN-329:
a few related things for reference:
4) immediate evaluation in general is wonky
5) the ConfigMap.findKeys method never looked at the keys declared on the
container; I'm tidying that in order to test the above
6) if a yaml subtype reclares a supertype's parameter (from yaml) or config key
(from java) only partially, the results are not merged as one would expect, but
instead all parts of the super's declaration are lost
(working on these together with 1/2)
> $brooklyn:config hangs, rather than getting default brooklyn.parameter value
>
>
> Key: BROOKLYN-329
> URL: https://issues.apache.org/jira/browse/BROOKLYN-329
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>Priority: Minor
>
> Using 0.10.0-SNAPSHOT...
> I wrote a YAML entity where CouchDB was configured with an initial
> username/password, and another app that included CouchDB would inject it.
> In each blueprint, I defined a brooklyn.parameter with a default value for
> the username/password. I used the same config key name in each.
> However, when I ran my blueprint it hung. The CouchDB was waiting forever for
> the username/password config value.
> I recreated this behaviour in the simpler test case below (which I'll add to
> {{ConfigParametersYamlTest}}).
> The workaround is to use a different name for the config key in each
> blueprint. For example, in the outer blueprint above if youchange the name to
> {{my.param.key2}} then the test passes.
> Debugging it, one surprising thing I noticed is that {{scopeRoot()}}
> evaluates to be "entity-with-tests" rather than {{wrapper-entity}}.
> {noformat}
> public void testConfigParameterPassedFromOuterConfigParameter() throws
> Exception {
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: entity-with-keys",
> "item:",
> " type: "+TestEntity.class.getName(),
> " brooklyn.parameters:",
> " - name: my.param.key",
> "type: string",
> "default: myDefaultVal",
> " brooklyn.config:",
> "my.other.key: $brooklyn:config(\"my.param.key\")");
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: wrapper-entity",
> "item:",
> " brooklyn.parameters:",
> " - name: my.param.key",
> "type: string",
> "default: myDefaultValInOuter",
> " type: entity-with-keys",
> " brooklyn.config:",
> "my.param.key:
> $brooklyn:scopeRoot().config(\"my.param.key\")");
>
> String yaml = Joiner.on("\n").join(
> "services:",
> "- type: wrapper-entity");
>
> Entity app = createStartWaitAndLogApplication(yaml);
> final TestEntity entity = (TestEntity)
> Iterables.getOnlyElement(app.getChildren());
> Asserts.assertReturnsEventually(new Runnable() {
> public void run() {
>
> assertEquals(entity.config().get(ConfigKeys.newStringConfigKey("my.other.key")),
> "myDefaultValInOuter");
> }},
> Asserts.DEFAULT_LONG_TIMEOUT);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-394) "Request limit exceeded" on Amazon
[
https://issues.apache.org/jira/browse/BROOKLYN-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15689990#comment-15689990
]
Alex Heneveld commented on BROOKLYN-394:
Has this resolved the issue, or simply improved it a bit ?
I tend to think this needs a fix in jclouds or our use of it: in particular
using the same rate limiter instance across all requests to a particular cloud
account + endpoint. The comments here suggest this isn't the case, back-off is
per thread/request, which means we'll keep banging our heads against this with
big clusters in parallel. The parameter tweaks here help us eke out a bit
higher success rate but don't solve the problem.
cc [~andreaturli] ?
> "Request limit exceeded" on Amazon
> --
>
> Key: BROOKLYN-394
> URL: https://issues.apache.org/jira/browse/BROOKLYN-394
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Svetoslav Neykov
>Assignee: Aled Sage
> Fix For: 0.10.0
>
>
> Any moderately sized blueprint could trigger {{Request limit exceeded}} on
> Amazon (say kubernetes). The only way users have control over the request
> rate is by setting {{maxConcurrentMachineCreations}} with the current
> recommended value of 3 (see clocker.io).
> It's bad user experience if one needs to adapt the location based on the
> blueprint.
> Possible steps to improve:
> * Add to troubleshooting documentation
> * Make maxConcurrentMachineCreations default to 3
> * Check are we polling for machine creation too often.
> * Check how many requests are we hitting Amazon with (per created machine)
> * The number of requests per machine could vary from blueprint to blueprint
> (say if the blueprint is creating security networks, using other amazon
> services). Is there a way to throttle our requests to amazon and stay below a
> certain limit per second?
> * I've hit the error during machine tear down as well, so
> {{maxConcurrentMachineCreations}} is not enough to work around
> Some docs on rate limits at
> http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html.
> Related: https://github.com/jclouds/legacy-jclouds/issues/1214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-375) Brooklyn intermittently uses high CPU levels and becomes unresponsive
[
https://issues.apache.org/jira/browse/BROOKLYN-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644080#comment-15644080
]
Alex Heneveld commented on BROOKLYN-375:
Should {{-XX:SoftRefLRUPolicyMSPerMB=1}} be included by default in startup
scripts (eg in {{brooklyn-dist/dist/src/main/dist/bin/}})?
> Brooklyn intermittently uses high CPU levels and becomes unresponsive
> -
>
> Key: BROOKLYN-375
> URL: https://issues.apache.org/jira/browse/BROOKLYN-375
> Project: Brooklyn
> Issue Type: Bug
> Environment: OSX Sierra, Java 1.7
>Reporter: Duncan Godwin
>
> Intermittently whilst launching a clocker swarm within brooklyn, it uses high
> CPU levels and becomes unresponsive. This was noted when testing failover by
> manally stopping some nodes with `shutdown -h`.
> [jstack 1|https://gist.github.com/drigodwin/c5946d23ed11350f393d9ba9b80a2a2d]
> [jstack 2|https://gist.github.com/drigodwin/5619b02c0c1d53ceb0c99234d8f0dd96]
> [jclouds.debug.log|https://gist.github.com/drigodwin/365d39d216e6a56c634a5020496ef8f1]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-266) NPE when deploying Riak Node on MacOS
[
https://issues.apache.org/jira/browse/BROOKLYN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277931#comment-15277931
]
Alex Heneveld commented on BROOKLYN-266:
Looks like this code no longer uses the resolver. Likely it's a simple change,
replace:
String saveAs = resolver.getFilename();
with
String saveAs = "riak-OSX.tar.gz";
> NPE when deploying Riak Node on MacOS
> -
>
> Key: BROOKLYN-266
> URL: https://issues.apache.org/jira/browse/BROOKLYN-266
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.10.0
> Environment: Mac OS
>Reporter: Thomas Bouron
>
> When deploying a simple Riak Node to MacOS, using the following blueprint:
> {code:borderStyle=solid}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.nosql.riak.RiakNode
> {code}
> The Riak node entity throws a NPE during the install phase with the following
> stack trace:
> {code}
> Failed after 0ms: NullPointerException
> java.lang.NullPointerException
> at
> org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.installMac(RiakNodeSshDriver.java:211)
> at
> org.apache.brooklyn.entity.nosql.riak.RiakNodeSshDriver.install(RiakNodeSshDriver.java:116)
> at
> org.apache.brooklyn.entity.software.base.AbstractSoftwareProcessDriver$2$6.run(AbstractSoftwareProcessDriver.java:159)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
> at
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-241) Many tests taking too long to run due to OSGi
[
https://issues.apache.org/jira/browse/BROOKLYN-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15199386#comment-15199386
]
Alex Heneveld commented on BROOKLYN-241:
I use this test fragment added to CatalogYamlTemplateTest
{code}
static Stopwatch elapsed, inTest;
static int iterCount = 0;
@Test(invocationCount=1000)
public void testSetupTime() throws Exception {
if (elapsed==null) {
elapsed = Stopwatch.createStarted();
inTest = Stopwatch.createUnstarted();
}
inTest.start();
testAddCatalogItem();
inTest.stop();
iterCount++;
Duration dInTest = Duration.of(inTest);
Duration dElapsed = Duration.of(elapsed);
System.err.println("Iter "+iterCount+"; "+dInTest+" / "+dElapsed+" in
test => setup/teardown time; "+
dElapsed.multiply(1.0/iterCount)+" mean per test cycle; "+
"setup/teardown taking
"+((int)(100*(dElapsed.toNanoseconds()-dInTest.toNanoseconds())/dElapsed.toNanoseconds()))+"
%" );
}
{code}
It's crude but effective; looking at stderr shows lines like:
{code}
Iter 139; 4s 396ms / 1m 13s 737ms in test => setup/teardown time; 530ms 482us
14ns mean per test cycle; setup/teardown taking 94 %
{code}
And running jstack-active while it's running suggests the culprit is OSGi:
{code}
at
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
at
org.apache.brooklyn.rt.felix.EmbeddedFelixFramework.installExtensionBundle(EmbeddedFelixFramework.java:209)
at
org.apache.brooklyn.rt.felix.EmbeddedFelixFramework.installBootBundles(EmbeddedFelixFramework.java:145)
at
org.apache.brooklyn.rt.felix.EmbeddedFelixFramework.newFrameworkStarted(EmbeddedFelixFramework.java:108)
at org.apache.brooklyn.util.core.osgi.Osgis.getFramework(Osgis.java:324)
at
org.apache.brooklyn.core.mgmt.ha.OsgiManager.start(OsgiManager.java:80)
at
org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(LocalManagementContext.java:196)
at
org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(LocalManagementContext.java:164)
at
org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(LocalManagementContext.java:156)
at
org.apache.brooklyn.core.mgmt.internal.LocalManagementContext.(LocalManagementContext.java:143)
at
org.apache.brooklyn.core.test.entity.LocalManagementContextForTests.(LocalManagementContextForTests.java:41)
{code}
(Since it's Felix not Karaf it's possible this is unrelated to the recent OSGi
work. I think I would have noticed earlier if CAMP REST API tests took >2m to
run but maybe not! Still, feels like we could improve build time dramatically
here.)
> Many tests taking too long to run due to OSGi
> -
>
> Key: BROOKLYN-241
> URL: https://issues.apache.org/jira/browse/BROOKLYN-241
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Since the introduction of Felix, a good number of our tests are taking a long
> time to run (eg 500ms average, for 100 or so tests; previously I'm pretty
> sure these were <100ms).
> As people build frequently this needs to be optimized.
> /cc [~svet] [~cipi] [~aled.sage]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BROOKLYN-239) Intermittent failing test: AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines
[
https://issues.apache.org/jira/browse/BROOKLYN-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld updated BROOKLYN-239:
---
Description:
does not seem to try to scale to 3 nodes. observed on (slow) apache jenkins PR
build:
https://builds.apache.org/job/brooklyn-server-pull-requests/org.apache.brooklyn$brooklyn-software-base/181/testReport/junit/org.apache.brooklyn.entity.software.base.test.autoscaling/AutoScalerPolicyNoMoreMachinesTest/testPoolHotSensorResizingBeyondMaxMachines/
maybe a timing issue causing it not to scale? would really help to see the
workspace / debug log for this but unfortunately it has been wiped by jenkins.
recording for posterity.
{code}
Error Message
failed succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError:
removed=[] expected [1] but found [0]
Stacktrace
org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError: removed=[]
expected [1] but found [0]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest$2.run(AutoScalerPolicyNoMoreMachinesTest.java:203)
at
org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1277)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:930)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:854)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:847)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.assertSizeEventually(AutoScalerPolicyNoMoreMachinesTest.java:200)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines(AutoScalerPolicyNoMoreMachinesTest.java:128)
Standard Output
2016-03-11 15:30:01,264 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
2016-03-11 15:30:01,269 INFO Stopping EmptySoftwareProcessImpl{id=RpkcofwJ} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:EHrV:null@1.1.1.2/1.1.1.2:22(id=EHrV9iEn)]]
2016-03-11 15:30:01,271 INFO Stopping EmptySoftwareProcessImpl{id=BCEPprmN} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:Uxre:null@1.1.1.1/1.1.1.1:22(id=UxretoRd)]]
2016-03-11 15:30:01,298 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
in 35 ms
2016-03-11 15:30:01,299 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
2016-03-11 15:30:01,363 INFO No Camp-YAML parser registered for parsing
catalog item DSL; skipping DSL-parsing
2016-03-11 15:30:01,405 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
finished in 106 ms
2016-03-11 15:30:01,406 INFO TESTNG INVOKING: "Surefire test" -
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines()
2016-03-11 15:30:01,407 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 0 to 1
2016-03-11 15:30:01,440 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,441 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu} on
machine
SshMachineLocation[SshMachineLocation:twp3:null@1.1.1.1/1.1.1.1:22(id=twp3JGLx)]
2016-03-11 15:30:01,599 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 1 to 2
2016-03-11 15:30:01,631 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,633 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07} on
machine
SshMachineLocation[SshMachineLocation:Wio6:null@1.1.1.2/1.1.1.2:22(id=Wio6talD)]
2016-03-11 15:30:31,633 INFO succeedsEventually exceeded max attempts or
timeout - 69 attempts lasting 3 ms, for
RunnableAdapter(org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest$2@7954e1de)
2016-03-11
[jira] [Updated] (BROOKLYN-239) Intermittent failing test: AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines
[
https://issues.apache.org/jira/browse/BROOKLYN-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld updated BROOKLYN-239:
---
Environment: jenkins (was:
does not seem to try to scale to 3 nodes. observed on (slow) apache jenkins PR
build:
https://builds.apache.org/job/brooklyn-server-pull-requests/org.apache.brooklyn$brooklyn-software-base/181/testReport/junit/org.apache.brooklyn.entity.software.base.test.autoscaling/AutoScalerPolicyNoMoreMachinesTest/testPoolHotSensorResizingBeyondMaxMachines/
maybe a timing issue causing it not to scale? would really help to see the
workspace / debug log for this but unfortunately it has been wiped by jenkins.
recording for posterity.
{code}
Error Message
failed succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError:
removed=[] expected [1] but found [0]
Stacktrace
org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError: removed=[]
expected [1] but found [0]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest$2.run(AutoScalerPolicyNoMoreMachinesTest.java:203)
at
org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1277)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:930)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:854)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:847)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.assertSizeEventually(AutoScalerPolicyNoMoreMachinesTest.java:200)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines(AutoScalerPolicyNoMoreMachinesTest.java:128)
Standard Output
2016-03-11 15:30:01,264 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
2016-03-11 15:30:01,269 INFO Stopping EmptySoftwareProcessImpl{id=RpkcofwJ} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:EHrV:null@1.1.1.2/1.1.1.2:22(id=EHrV9iEn)]]
2016-03-11 15:30:01,271 INFO Stopping EmptySoftwareProcessImpl{id=BCEPprmN} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:Uxre:null@1.1.1.1/1.1.1.1:22(id=UxretoRd)]]
2016-03-11 15:30:01,298 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
in 35 ms
2016-03-11 15:30:01,299 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
2016-03-11 15:30:01,363 INFO No Camp-YAML parser registered for parsing
catalog item DSL; skipping DSL-parsing
2016-03-11 15:30:01,405 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
finished in 106 ms
2016-03-11 15:30:01,406 INFO TESTNG INVOKING: "Surefire test" -
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines()
2016-03-11 15:30:01,407 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 0 to 1
2016-03-11 15:30:01,440 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,441 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu} on
machine
SshMachineLocation[SshMachineLocation:twp3:null@1.1.1.1/1.1.1.1:22(id=twp3JGLx)]
2016-03-11 15:30:01,599 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 1 to 2
2016-03-11 15:30:01,631 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,633 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07} on
machine
SshMachineLocation[SshMachineLocation:Wio6:null@1.1.1.2/1.1.1.2:22(id=Wio6talD)]
2016-03-11 15:30:31,633 INFO succeedsEventually exceeded max attempts or
timeout - 69 attempts lasting 3 ms, for
RunnableAdapter(org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest$2@7954e1de)
[jira] [Created] (BROOKLYN-239) Intermittent failing test: AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines
Alex Heneveld created BROOKLYN-239:
--
Summary: Intermittent failing test:
AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines
Key: BROOKLYN-239
URL: https://issues.apache.org/jira/browse/BROOKLYN-239
Project: Brooklyn
Issue Type: Bug
Environment:
does not seem to try to scale to 3 nodes. observed on (slow) apache jenkins PR
build:
https://builds.apache.org/job/brooklyn-server-pull-requests/org.apache.brooklyn$brooklyn-software-base/181/testReport/junit/org.apache.brooklyn.entity.software.base.test.autoscaling/AutoScalerPolicyNoMoreMachinesTest/testPoolHotSensorResizingBeyondMaxMachines/
maybe a timing issue causing it not to scale? would really help to see the
workspace / debug log for this but unfortunately it has been wiped by jenkins.
recording for posterity.
{code}
Error Message
failed succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError:
removed=[] expected [1] but found [0]
Stacktrace
org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: failed
succeeds-eventually, 69 attempts, 30001ms elapsed: AssertionError: removed=[]
expected [1] but found [0]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest$2.run(AutoScalerPolicyNoMoreMachinesTest.java:203)
at
org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1277)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:930)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:854)
at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:847)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.assertSizeEventually(AutoScalerPolicyNoMoreMachinesTest.java:200)
at
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines(AutoScalerPolicyNoMoreMachinesTest.java:128)
Standard Output
2016-03-11 15:30:01,264 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
2016-03-11 15:30:01,269 INFO Stopping EmptySoftwareProcessImpl{id=RpkcofwJ} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:EHrV:null@1.1.1.2/1.1.1.2:22(id=EHrV9iEn)]]
2016-03-11 15:30:01,271 INFO Stopping EmptySoftwareProcessImpl{id=BCEPprmN} in
[FixedListMachineProvisioningLocation{id=OFJrKbG7,
name=FixedListMachineProvisioningLocation:OFJr},
SshMachineLocation[SshMachineLocation:Uxre:null@1.1.1.1/1.1.1.1:22(id=UxretoRd)]]
2016-03-11 15:30:01,298 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
in 35 ms
2016-03-11 15:30:01,299 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
2016-03-11 15:30:01,363 INFO No Camp-YAML parser registered for parsing
catalog item DSL; skipping DSL-parsing
2016-03-11 15:30:01,405 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.setUp()
finished in 106 ms
2016-03-11 15:30:01,406 INFO TESTNG INVOKING: "Surefire test" -
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testPoolHotSensorResizingBeyondMaxMachines()
2016-03-11 15:30:01,407 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 0 to 1
2016-03-11 15:30:01,440 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,441 INFO Starting EmptySoftwareProcessImpl{id=a1VtHWCu} on
machine
SshMachineLocation[SshMachineLocation:twp3:null@1.1.1.1/1.1.1.1:22(id=twp3JGLx)]
2016-03-11 15:30:01,599 INFO Resize DynamicClusterImpl{id=t02HU0Ue} from 1 to 2
2016-03-11 15:30:01,631 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07},
obtaining a new location instance in
FixedListMachineProvisioningLocation{id=qJFayMMf,
name=FixedListMachineProvisioningLocation:qJFa} with ports [22]
2016-03-11 15:30:01,633 INFO Starting EmptySoftwareProcessImpl{id=zMZMnt07} on
machine
SshMachineLocation[SshMachineLocation:Wio6:null@1.1.1.2/1.1.1.2:22(id=Wio6talD)]
2016-03-11 15:30:31,633 INFO succeedsEventually exceeded max attempts or
timeout -
[jira] [Commented] (BROOKLYN-229) Get IllegalArgumentException by the use of the keypair parameter in a namedlocation
[
https://issues.apache.org/jira/browse/BROOKLYN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187023#comment-15187023
]
Alex Heneveld commented on BROOKLYN-229:
Guessing this isn't supported with the current winrm module? I've not tried
that for auth but maybe other auth techniques are preferred there?
Any idea how easy this looks to fix? And how important is it for you?
> Get IllegalArgumentException by the use of the keypair parameter in a
> namedlocation
> ---
>
> Key: BROOKLYN-229
> URL: https://issues.apache.org/jira/browse/BROOKLYN-229
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Felix Otto
>
> For any new ec2 instance automatically a new key pair will be generated in
> AWS by the jcloud implementation. After some research we find out that it is
> possible to set the keypair in the named location of the brooklyn.properties
> file. If we set the keypair in the named location than we get the following
> error:
> log:
> {code}
> java.lang.IllegalArgumentException: no private key configured for:
> {region=eu-central-1, name=01-brooklyn}; please use
> options.overrideLoginCredentialWith(rsa_private_text)
> {code}
> brooklyn.properties:
> {code}
> brooklyn.location.named.aws-frankfurt= jclouds:aws-ec2:eu-central-1
> brooklyn.location.named.aws-frankfurt.displayName=AWS Frankfurt
> (ida-01-brooklyn)
> brooklyn.location.named.aws-frankfurt.identity=
> brooklyn.location.named.aws-frankfurt.credential=
> brooklyn.location.named.aws-frankfurt.keyPair=01-brooklyn
> brooklyn.location.named.aws-frankfurt.privateKeyFile=/home/ubuntu/.ssh/id_rsa
> brooklyn.location.named.aws-frankfurt.publicKeyFile=/home/ubuntu/.ssh/id_rsa.pub
> {code}
> This cause for this problem can be found in the class
> org.jclouds.ec2.compute.strategy.CreateKeyPairAndSecurityGroupsAsNeededAndReturnRunOptions
> line 128
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
[
https://issues.apache.org/jira/browse/BROOKLYN-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166785#comment-15166785
]
Alex Heneveld commented on BROOKLYN-231:
pretty sure fixed by https://github.com/apache/brooklyn-server/pull/40
> Unpredictable test, deleting catalog item not guaranteed through persistence
>
>
> Key: BROOKLYN-231
> URL: https://issues.apache.org/jira/browse/BROOKLYN-231
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Observed in
> https://builds.apache.org/job/brooklyn-master-build/org.apache.brooklyn$brooklyn-core/19/testReport/junit/org.apache.brooklyn.core.mgmt.rebind/RebindCatalogItemTest/testAddAndRebindAndDeleteLocation/
> From the error message it looks like the deletion is not guaranteed to be
> picked up by persistence.
> Error Message
> Sets differ: expected [com.example.ExampleApp:9.1.3] but got
> [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
> Stacktrace
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.assertEquals(Assert.java:806)
> at org.testng.Assert.assertEquals(Assert.java:784)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
> Standard Output
> 2016-02-17 01:01:11,412 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2016-02-17 01:01:11,421 WARN Setting Application[M6UGmDSN] on-fire due to
> problems when expected running, up=false, not-up-indicators:
> {service.state=Application stopping}
> 2016-02-17 01:01:11,428 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
> in 16 ms
> 2016-02-17 01:01:11,429 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp()
> 2016-02-17 01:01:11,538 INFO Test class
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest persisting to
> /tmp/RebindCatalogItemTest-HOPQ
> 2016-02-17 01:01:11,555 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp() finished
> in 127 ms
> 2016-02-17 01:01:11,556 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> 2016-02-17 01:01:11,558 WARN Legacy CatalogLoadMode
> LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be changed to use
> new CLI --catalogXxx commands
> 2016-02-17 01:01:11,595 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,681 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master TvJBFrIf...
> 2016-02-17 01:01:11,724 INFO Rebind complete (MASTER) in 121ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,741 INFO Deleted item from catalog: sample_location:0.0.1
> 2016-02-17 01:01:11,749 INFO Count of incomplete tasks now 0, 0 unended;
> tasks remembered are: []
> 2016-02-17 01:01:11,757 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,797 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master fTqApBF7...
> 2016-02-17 01:01:11,846 INFO Rebind complete (MASTER) in 81ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,885 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> finished in 328 ms
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
[
https://issues.apache.org/jira/browse/BROOKLYN-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166780#comment-15166780
]
Alex Heneveld commented on BROOKLYN-231:
actually BROOKLYN-204 seems a different cause. it's now looking like mgmt2
(aka XmCah7ox) is updating sample_location (the deleted item) and deleting it
in the same iteration, whereas the successful tests run faster and do that on
two iterations. i'm wondering if that's the cause.
> Unpredictable test, deleting catalog item not guaranteed through persistence
>
>
> Key: BROOKLYN-231
> URL: https://issues.apache.org/jira/browse/BROOKLYN-231
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Observed in
> https://builds.apache.org/job/brooklyn-master-build/org.apache.brooklyn$brooklyn-core/19/testReport/junit/org.apache.brooklyn.core.mgmt.rebind/RebindCatalogItemTest/testAddAndRebindAndDeleteLocation/
> From the error message it looks like the deletion is not guaranteed to be
> picked up by persistence.
> Error Message
> Sets differ: expected [com.example.ExampleApp:9.1.3] but got
> [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
> Stacktrace
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.assertEquals(Assert.java:806)
> at org.testng.Assert.assertEquals(Assert.java:784)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
> Standard Output
> 2016-02-17 01:01:11,412 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2016-02-17 01:01:11,421 WARN Setting Application[M6UGmDSN] on-fire due to
> problems when expected running, up=false, not-up-indicators:
> {service.state=Application stopping}
> 2016-02-17 01:01:11,428 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
> in 16 ms
> 2016-02-17 01:01:11,429 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp()
> 2016-02-17 01:01:11,538 INFO Test class
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest persisting to
> /tmp/RebindCatalogItemTest-HOPQ
> 2016-02-17 01:01:11,555 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp() finished
> in 127 ms
> 2016-02-17 01:01:11,556 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> 2016-02-17 01:01:11,558 WARN Legacy CatalogLoadMode
> LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be changed to use
> new CLI --catalogXxx commands
> 2016-02-17 01:01:11,595 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,681 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master TvJBFrIf...
> 2016-02-17 01:01:11,724 INFO Rebind complete (MASTER) in 121ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,741 INFO Deleted item from catalog: sample_location:0.0.1
> 2016-02-17 01:01:11,749 INFO Count of incomplete tasks now 0, 0 unended;
> tasks remembered are: []
> 2016-02-17 01:01:11,757 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,797 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master fTqApBF7...
> 2016-02-17 01:01:11,846 INFO Rebind complete (MASTER) in 81ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,885 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> finished in 328 ms
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
[jira] [Commented] (BROOKLYN-204) Unpredictable test: HotStandbyTest.testChangeMode
[
https://issues.apache.org/jira/browse/BROOKLYN-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166543#comment-15166543
]
Alex Heneveld commented on BROOKLYN-204:
actually not the same as BROOKLYN-231 -- this one is just us assuming rebind
has completed when there is no guarantee that it has. fixed in
401d05a829bd330596a3dc749f3539008d103b5f
> Unpredictable test: HotStandbyTest.testChangeMode
> -
>
> Key: BROOKLYN-204
> URL: https://issues.apache.org/jira/browse/BROOKLYN-204
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Build output:
> {code}
> java.lang.AssertionError: expected [second-app] but found [defaultval]
> at
> org.apache.brooklyn.core.mgmt.ha.HotStandbyTest.testChangeMode(HotStandbyTest.java:537)
> ... Removed 33 stack frames
> {code}
> Log:
> {code}
> 2015-12-14 15:59:22,642 INFO o.a.b.t.s.LoggingVerboseReporter [main]: TESTNG
> INVOKING CONFIGURATION: "Surefire test" - @BeforeMethod
> org.apache.brooklyn.core.mgmt.ha.HotStandbyTest.setUp()
> 2015-12-14 15:59:22,642 INFO o.a.b.t.s.LoggingVerboseReporter [main]: TESTNG
> PASSED CONFIGURATION: "Surefire test" - @BeforeMethod
> org.apache.brooklyn.core.mgmt.ha.HotStandbyTest.setUp() finished in 0 ms
> 2015-12-14 15:59:22,642 INFO o.a.b.t.s.LoggingVerboseReporter [main]: TESTNG
> INVOKING: "Surefire test" -
> org.apache.brooklyn.core.mgmt.ha.HotStandbyTest.testChangeMode()
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.e.d.ReflectiveEntityDriverFactory
> [main]: Added driver mapping rule
> org.apache.brooklyn.core.entity.drivers.ReflectiveEntityDriverFactory$DriverInferenceForSshLocation@c93275f
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.e.d.ReflectiveEntityDriverFactory
> [main]: Added driver mapping rule
> org.apache.brooklyn.core.entity.drivers.ReflectiveEntityDriverFactory$DriverInferenceForPaasLocation@37711f1a
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.e.d.ReflectiveEntityDriverFactory
> [main]: Added driver mapping rule
> org.apache.brooklyn.core.entity.drivers.ReflectiveEntityDriverFactory$DriverInferenceForWinRmLocation@2182cd7c
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.m.r.RebindManagerImpl [main]:
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl@10939bc1[mgmt=null]
> initialized, settings: policies=true, enrichers=true, feeds=true, catalog=true
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.BrooklynFeatureEnablement [main]: Init
> feature enablement did nothing, as no settings in brooklyn properties
> 2015-12-14 15:59:22,642 DEBUG o.a.b.c.m.i.LocalManagementContext [main]:
> Created management context LocalManagementContext[D2gDJQKx-dIEUU7iP]
> 2015-12-14 15:59:22,643 DEBUG o.a.b.c.m.p.InMemoryObjectStore [main]: Using
> memory-based objectStore
> 2015-12-14 15:59:22,644 DEBUG
> o.a.b.c.m.h.ManagementPlaneSyncRecordPersisterToObjectStore [main]:
> ManagementPlaneMemento-persister will use store
> org.apache.brooklyn.core.mgmt.persist.ListeningObjectStore@d476a21
> 2015-12-14 15:59:22,645 INFO o.a.b.c.mgmt.ha.HotStandbyTest [main]: Created
> node 0 dIEUU7iP
> 2015-12-14 15:59:22,645 DEBUG
> o.a.b.c.m.h.ManagementPlaneSyncRecordPersisterToObjectStore [main]: No
> master-memento deserialized from file
> StoreObjectAccessorLocking:org.apache.brooklyn.core.mgmt.persist.ListeningObjectStore$ListeningAccessor@c0ef9a8;
> ignoring and continuing (normal on startup, should cause an error later in
> live operation)
> 2015-12-14 15:59:22,645 DEBUG o.a.b.c.m.h.HighAvailabilityManagerImpl [main]:
> Healthy-master check result=false; masterId=null; masterMemento=;
> ourMemento=
> 2015-12-14 15:59:22,645 DEBUG
> o.a.b.c.m.h.ManagementPlaneSyncRecordPersisterToObjectStore [main]:
> Checkpointed delta of manager-memento in 0ms:
> org.apache.brooklyn.core.mgmt.ha.ManagementPlaneSyncRecordDeltaImpl[nodes:
> [BasicManagementNodeSyncRecord{nodeId=dIEUU7iP, status=STANDBY}]]
> 2015-12-14 15:59:22,645 DEBUG
> o.a.b.c.m.h.ManagementPlaneSyncRecordPersisterToObjectStore [main]: No
> master-memento deserialized from file
> StoreObjectAccessorLocking:org.apache.brooklyn.core.mgmt.persist.ListeningObjectStore$ListeningAccessor@c0ef9a8;
> ignoring and continuing (normal on startup, should cause an error later in
> live operation)
> 2015-12-14 15:59:22,646 DEBUG o.a.b.c.m.h.HighAvailabilityManagerImpl [main]:
> Detected master heartbeat timeout. Initiating a new master election. Master
> was null
> 2015-12-14 15:59:22,646 DEBUG o.a.b.c.m.h.BasicMasterChooser [main]: Choosing
> new master from {dIEUU7iP=BasicManagementNodeSyncRecord{nodeId=dIEUU7iP,
> status=STANDBY}}
> 2015-12-14 15:59:22,646 DEBUG o.a.b.c.m.h.HighAvailabilityManagerImpl [main]:
> Management node master-change required:
> newMaster=BasicManagementNodeSyncRecord{brooklynVersion=0.9.0-SNAPSHOT,
> nodeId=dIEUU7iP, status=STANDBY, priority=0,
>
[jira] [Commented] (BROOKLYN-203) Unpredictable test: ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp
[
https://issues.apache.org/jira/browse/BROOKLYN-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166530#comment-15166530
]
Alex Heneveld commented on BROOKLYN-203:
hopefully fixed by https://github.com/apache/brooklyn-server/pull/39
> Unpredictable test: ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp
>
>
> Key: BROOKLYN-203
> URL: https://issues.apache.org/jira/browse/BROOKLYN-203
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Broke in https://github.com/apache/incubator-brooklyn/pull/1095.
> Error Message
> {code}
> entity=TestJavaWebAppEntityImpl{id=IbVX3MAT}; attribute=Sensor: service.isUp
> (java.lang.Boolean) expected [false] but found [true]
> {code}
> Stacktrace
> {code}
> java.lang.AssertionError: entity=TestJavaWebAppEntityImpl{id=IbVX3MAT};
> attribute=Sensor: service.isUp (java.lang.Boolean) expected [false] but found
> [true]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEquals(EntityTestUtils.java:62)
> at
> org.apache.brooklyn.test.EntityTestUtils$1.run(EntityTestUtils.java:78)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1210)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:872)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:799)
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEqualsEventually(EntityTestUtils.java:75)
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEqualsEventually(EntityTestUtils.java:70)
> at
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp(ControlledDynamicWebAppClusterTest.java:134)
> {code}
> Standard Output
> {code}
> 2015-12-09 13:15:04,935 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.setUp()
> 2015-12-09 13:15:04,971 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.setUp()
> finished in 36 ms
> 2015-12-09 13:15:04,971 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp()
> 2015-12-09 13:15:35,017 INFO succeedsEventually exceeded max attempts or
> timeout - 69 attempts lasting 3 ms, for
> RunnableAdapter(org.apache.brooklyn.test.EntityTestUtils$1@7f5823b6)
> 2015-12-09 13:15:35,017 INFO failed succeeds-eventually, 69 attempts,
> 3ms elapsed (rethrowing): java.lang.AssertionError:
> entity=TestJavaWebAppEntityImpl{id=IbVX3MAT}; attribute=Sensor: service.isUp
> (java.lang.Boolean) expected [false] but found [true]
> 2015-12-09 13:15:35,020 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp()
> finished in 30047 ms
> java.lang.AssertionError: entity=TestJavaWebAppEntityImpl{id=IbVX3MAT};
> attribute=Sensor: service.isUp (java.lang.Boolean) expected [false] but found
> [true]
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEquals(EntityTestUtils.java:62)
> at
> org.apache.brooklyn.test.EntityTestUtils$1.run(EntityTestUtils.java:78)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1210)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:872)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:799)
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEqualsEventually(EntityTestUtils.java:75)
> at
> org.apache.brooklyn.test.EntityTestUtils.assertAttributeEqualsEventually(EntityTestUtils.java:70)
> at
> org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppClusterTest.testTheTestJavaWebApp(ControlledDynamicWebAppClusterTest.java:134){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
[
https://issues.apache.org/jira/browse/BROOKLYN-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166518#comment-15166518
]
Alex Heneveld commented on BROOKLYN-231:
BTW possibly the same as BROOKLYN-204
> Unpredictable test, deleting catalog item not guaranteed through persistence
>
>
> Key: BROOKLYN-231
> URL: https://issues.apache.org/jira/browse/BROOKLYN-231
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Observed in
> https://builds.apache.org/job/brooklyn-master-build/org.apache.brooklyn$brooklyn-core/19/testReport/junit/org.apache.brooklyn.core.mgmt.rebind/RebindCatalogItemTest/testAddAndRebindAndDeleteLocation/
> From the error message it looks like the deletion is not guaranteed to be
> picked up by persistence.
> Error Message
> Sets differ: expected [com.example.ExampleApp:9.1.3] but got
> [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
> Stacktrace
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.assertEquals(Assert.java:806)
> at org.testng.Assert.assertEquals(Assert.java:784)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
> Standard Output
> 2016-02-17 01:01:11,412 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2016-02-17 01:01:11,421 WARN Setting Application[M6UGmDSN] on-fire due to
> problems when expected running, up=false, not-up-indicators:
> {service.state=Application stopping}
> 2016-02-17 01:01:11,428 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
> in 16 ms
> 2016-02-17 01:01:11,429 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp()
> 2016-02-17 01:01:11,538 INFO Test class
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest persisting to
> /tmp/RebindCatalogItemTest-HOPQ
> 2016-02-17 01:01:11,555 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp() finished
> in 127 ms
> 2016-02-17 01:01:11,556 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> 2016-02-17 01:01:11,558 WARN Legacy CatalogLoadMode
> LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be changed to use
> new CLI --catalogXxx commands
> 2016-02-17 01:01:11,595 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,681 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master TvJBFrIf...
> 2016-02-17 01:01:11,724 INFO Rebind complete (MASTER) in 121ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,741 INFO Deleted item from catalog: sample_location:0.0.1
> 2016-02-17 01:01:11,749 INFO Count of incomplete tasks now 0, 0 unended;
> tasks remembered are: []
> 2016-02-17 01:01:11,757 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,797 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master fTqApBF7...
> 2016-02-17 01:01:11,846 INFO Rebind complete (MASTER) in 81ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,885 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> finished in 328 ms
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (BROOKLYN-206) Unreliable test: AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
[
https://issues.apache.org/jira/browse/BROOKLYN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld updated BROOKLYN-206:
---
Comment: was deleted
(was: what the test does is
* mgmt1 has 2 catalog items
* rebinds into mgmt2
* mgmt2 deletes 1 catalog item
* rebinds into mgmt3
* checks mgmt3 has 1 catalog item
it's failing at the last step, mgmt3 has 2 catalog items. the debug log
reveals that there is a thread probably from mgmt1 writing 2 catalog items
AFTER mgmt2 writes the 1 catalog item. (search for "checkpointed".)
need to check why mgmt1 is not ending. i think we're not running with HA so
it's probably a test issue, not shutting it down cleanly.)
> Unreliable test:
> AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
> ---
>
> Key: BROOKLYN-206
> URL: https://issues.apache.org/jira/browse/BROOKLYN-206
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Stacktrace
> {code}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> {code}
> Debug log
> {code}
> 2015-12-15 15:30:17,853 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> 2015-12-15 15:30:18,096 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x}, obtaining a new location
> instance in FixedListMachineProvisioningLocation{id=HsQneYPD,
> name=FixedListMachineProvisioningLocation:HsQn} with ports [22, 8000, 8443]
> 2015-12-15 15:30:18,108 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x} on machine
> SshMachineLocation[SshMachineLocation:TM32:null@/1.1.1.1:22(id=TM32DuVH)]
> 2015-12-15 15:30:18,242 INFO Added policy
> ServerPoolMemberTrackerPolicy{name=Controller targets tracker, running=true}
> to TrackingAbstractControllerImpl{id=Zveoz16x}
> 2015-12-15 15:30:18,242 INFO Resetting
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO Updating
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO test controller reconfigure, targets []
> 2015-12-15 15:30:18,252 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> finished in 399 ms
> 2015-12-15 15:30:18,253 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> 2015-12-15 15:30:33,398 INFO succeedsEventually exceeded max attempts or
> timeout - 39 attempts lasting 15001 ms, for
> RunnableAdapter(org.apache.brooklyn.entity.proxy.AbstractControllerTest$3@186540e1)
> 2015-12-15 15:30:33,398 INFO failed succeeds-eventually, 39 attempts,
> 15001ms elapsed (rethrowing): java.lang.AssertionError: expected [true] but
> found [false]
> 2015-12-15 15:30:33,401 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> finished in 15147 ms
> java.lang.AssertionError: expected [true] but found [false]
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest$3.run(AbstractControllerTest.java:300)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1208)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:870)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:797)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertEventuallyExplicitAddressesMatch(AbstractControllerTest.java:298)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges(AbstractControllerTest.java:120)
> 2015-12-15 15:30:33,406 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2015-12-15 15:30:33,417 INFO Stopping
> TrackingAbstractControllerImpl{id=Zveoz16x} in
>
[jira] [Commented] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
[
https://issues.apache.org/jira/browse/BROOKLYN-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166516#comment-15166516
]
Alex Heneveld commented on BROOKLYN-231:
got debug log from jenkins workspace on failure at builds.apache.org
{code}
2016-02-24 23:34:52,276 INFO o.a.b.t.s.LoggingVerboseReporter [main]: TESTNG
INVOKING: "Surefire test" -
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
2016-02-24 23:34:52,278 DEBUG o.a.b.c.c.i.CatalogInitialization [main]:
Populating catalog unofficially
(org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528)
2016-02-24 23:34:52,278 WARN o.a.b.c.c.i.CatalogInitialization [main]: Legacy
CatalogLoadMode LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be
changed to use new CLI --catalogXxx commands
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.CatalogInitialization [main]: Loading
initial catalog from
classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Forcing
catalog load on access of catalog items
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Loading
catalog for LocalManagementContext[E5deSfFR-xoVyTRQg]
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=empty catalog, contentsDescription=empty
catalog, expected to be reset later}(not yet loaded) into null
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=empty catalog, contentsDescription=empty
catalog, expected to be reset later}(not yet loaded)
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Loaded
catalog for LocalManagementContext[E5deSfFR-xoVyTRQg]:
Loaded:CatalogDto{name=empty catalog, contentsDescription=empty catalog,
expected to be reset later}(size 0); search classpath is
AggregateClassLoader[sun.misc.Launcher$AppClassLoader@46c6c084,
AggregateClassLoader[]]
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]:
Resetting
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528 catalog
to CatalogDto{contentsDescription=explicit-catalog-reset}
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{contentsDescription=explicit-catalog-reset}(not yet
loaded) into null
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{contentsDescription=explicit-catalog-reset}(not yet
loaded)
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Reloaded
catalog for
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528, now
switching
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Adding
manual catalog item to LocalManagementContext[E5deSfFR-xoVyTRQg]:
Rebind catalog item test
An example application
http://www.example.com/icon.jpg
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDto [main]: Retrieved
catalog from:
classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]:
Resetting
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528 catalog
to CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(not
yet loaded) into null
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(not
yet loaded)
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Reloaded
catalog for
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528, now
switching
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Adding
manual catalog item to LocalManagementContext[E5deSfFR-xoVyTRQg]:
CatalogLocationItemDto[sample_location:0.0.1/sample_location]
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=Manual Catalog Additions,
contentsDescription=manual-additions}(not yet loaded) into
Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(size
1)
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=Manual Catalog Additions,
contentsDescription=manual-additions}(not
[jira] [Commented] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
[
https://issues.apache.org/jira/browse/BROOKLYN-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166517#comment-15166517
]
Alex Heneveld commented on BROOKLYN-231:
what the test does is
* mgmt1 has 2 catalog items
* rebinds into mgmt2
* mgmt2 deletes 1 catalog item
* rebinds into mgmt3
* checks mgmt3 has 1 catalog item
it's failing at the last step, mgmt3 has 2 catalog items. the debug log
reveals that there is a thread probably from mgmt1 writing 2 catalog items
AFTER mgmt2 writes the 1 catalog item. (search for "checkpointed".)
need to check why mgmt1 is not ending. i think we're not running with HA so
it's probably a test issue, not shutting it down cleanly.
> Unpredictable test, deleting catalog item not guaranteed through persistence
>
>
> Key: BROOKLYN-231
> URL: https://issues.apache.org/jira/browse/BROOKLYN-231
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Alex Heneveld
>
> Observed in
> https://builds.apache.org/job/brooklyn-master-build/org.apache.brooklyn$brooklyn-core/19/testReport/junit/org.apache.brooklyn.core.mgmt.rebind/RebindCatalogItemTest/testAddAndRebindAndDeleteLocation/
> From the error message it looks like the deletion is not guaranteed to be
> picked up by persistence.
> Error Message
> Sets differ: expected [com.example.ExampleApp:9.1.3] but got
> [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
> Stacktrace
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.assertEquals(Assert.java:806)
> at org.testng.Assert.assertEquals(Assert.java:784)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
> Standard Output
> 2016-02-17 01:01:11,412 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2016-02-17 01:01:11,421 WARN Setting Application[M6UGmDSN] on-fire due to
> problems when expected running, up=false, not-up-indicators:
> {service.state=Application stopping}
> 2016-02-17 01:01:11,428 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
> in 16 ms
> 2016-02-17 01:01:11,429 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp()
> 2016-02-17 01:01:11,538 INFO Test class
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest persisting to
> /tmp/RebindCatalogItemTest-HOPQ
> 2016-02-17 01:01:11,555 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp() finished
> in 127 ms
> 2016-02-17 01:01:11,556 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> 2016-02-17 01:01:11,558 WARN Legacy CatalogLoadMode
> LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be changed to use
> new CLI --catalogXxx commands
> 2016-02-17 01:01:11,595 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,681 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master TvJBFrIf...
> 2016-02-17 01:01:11,724 INFO Rebind complete (MASTER) in 121ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,741 INFO Deleted item from catalog: sample_location:0.0.1
> 2016-02-17 01:01:11,749 INFO Count of incomplete tasks now 0, 0 unended;
> tasks remembered are: []
> 2016-02-17 01:01:11,757 INFO Rebinding app, using mementoDir
> /tmp/RebindCatalogItemTest-HOPQ; object store null
> 2016-02-17 01:01:11,797 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
> for master fTqApBF7...
> 2016-02-17 01:01:11,846 INFO Rebind complete (MASTER) in 81ms: 1 app, 2
> entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
> 2016-02-17 01:01:11,885 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
> finished in 328 ms
> java.lang.AssertionError: Sets differ: expected
> [com.example.ExampleApp:9.1.3] but got [com.example.ExampleApp:9.1.3,
> sample_location:0.0.1]
> at
>
[jira] [Commented] (BROOKLYN-206) Unreliable test: AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
[
https://issues.apache.org/jira/browse/BROOKLYN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166514#comment-15166514
]
Alex Heneveld commented on BROOKLYN-206:
what the test does is
* mgmt1 has 2 catalog items
* rebinds into mgmt2
* mgmt2 deletes 1 catalog item
* rebinds into mgmt3
* checks mgmt3 has 1 catalog item
it's failing at the last step, mgmt3 has 2 catalog items. the debug log
reveals that there is a thread probably from mgmt1 writing 2 catalog items
AFTER mgmt2 writes the 1 catalog item. (search for "checkpointed".)
need to check why mgmt1 is not ending. i think we're not running with HA so
it's probably a test issue, not shutting it down cleanly.
> Unreliable test:
> AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
> ---
>
> Key: BROOKLYN-206
> URL: https://issues.apache.org/jira/browse/BROOKLYN-206
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Stacktrace
> {code}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> {code}
> Debug log
> {code}
> 2015-12-15 15:30:17,853 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> 2015-12-15 15:30:18,096 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x}, obtaining a new location
> instance in FixedListMachineProvisioningLocation{id=HsQneYPD,
> name=FixedListMachineProvisioningLocation:HsQn} with ports [22, 8000, 8443]
> 2015-12-15 15:30:18,108 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x} on machine
> SshMachineLocation[SshMachineLocation:TM32:null@/1.1.1.1:22(id=TM32DuVH)]
> 2015-12-15 15:30:18,242 INFO Added policy
> ServerPoolMemberTrackerPolicy{name=Controller targets tracker, running=true}
> to TrackingAbstractControllerImpl{id=Zveoz16x}
> 2015-12-15 15:30:18,242 INFO Resetting
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO Updating
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO test controller reconfigure, targets []
> 2015-12-15 15:30:18,252 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> finished in 399 ms
> 2015-12-15 15:30:18,253 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> 2015-12-15 15:30:33,398 INFO succeedsEventually exceeded max attempts or
> timeout - 39 attempts lasting 15001 ms, for
> RunnableAdapter(org.apache.brooklyn.entity.proxy.AbstractControllerTest$3@186540e1)
> 2015-12-15 15:30:33,398 INFO failed succeeds-eventually, 39 attempts,
> 15001ms elapsed (rethrowing): java.lang.AssertionError: expected [true] but
> found [false]
> 2015-12-15 15:30:33,401 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> finished in 15147 ms
> java.lang.AssertionError: expected [true] but found [false]
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest$3.run(AbstractControllerTest.java:300)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1208)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:870)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:797)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertEventuallyExplicitAddressesMatch(AbstractControllerTest.java:298)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges(AbstractControllerTest.java:120)
> 2015-12-15 15:30:33,406 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2015-12-15 15:30:33,417 INFO Stopping
> TrackingAbstractControllerImpl{id=Zveoz16x} in
>
[jira] [Commented] (BROOKLYN-206) Unreliable test: AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
[
https://issues.apache.org/jira/browse/BROOKLYN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166472#comment-15166472
]
Alex Heneveld commented on BROOKLYN-206:
got debug log from jenkins workspace on failure at builds.apache.org
{code}
2016-02-24 23:34:52,276 INFO o.a.b.t.s.LoggingVerboseReporter [main]: TESTNG
INVOKING: "Surefire test" -
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
2016-02-24 23:34:52,278 DEBUG o.a.b.c.c.i.CatalogInitialization [main]:
Populating catalog unofficially
(org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528)
2016-02-24 23:34:52,278 WARN o.a.b.c.c.i.CatalogInitialization [main]: Legacy
CatalogLoadMode LOAD_BROOKLYN_CATALOG_URL set: applying, but this should be
changed to use new CLI --catalogXxx commands
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.CatalogInitialization [main]: Loading
initial catalog from
classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Forcing
catalog load on access of catalog items
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Loading
catalog for LocalManagementContext[E5deSfFR-xoVyTRQg]
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=empty catalog, contentsDescription=empty
catalog, expected to be reset later}(not yet loaded) into null
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=empty catalog, contentsDescription=empty
catalog, expected to be reset later}(not yet loaded)
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Loaded
catalog for LocalManagementContext[E5deSfFR-xoVyTRQg]:
Loaded:CatalogDto{name=empty catalog, contentsDescription=empty catalog,
expected to be reset later}(size 0); search classpath is
AggregateClassLoader[sun.misc.Launcher$AppClassLoader@46c6c084,
AggregateClassLoader[]]
2016-02-24 23:34:52,279 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]:
Resetting
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528 catalog
to CatalogDto{contentsDescription=explicit-catalog-reset}
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{contentsDescription=explicit-catalog-reset}(not yet
loaded) into null
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{contentsDescription=explicit-catalog-reset}(not yet
loaded)
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Reloaded
catalog for
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528, now
switching
2016-02-24 23:34:52,280 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Adding
manual catalog item to LocalManagementContext[E5deSfFR-xoVyTRQg]:
Rebind catalog item test
An example application
http://www.example.com/icon.jpg
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDto [main]: Retrieved
catalog from:
classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]:
Resetting
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528 catalog
to CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(not
yet loaded) into null
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(not
yet loaded)
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Reloaded
catalog for
org.apache.brooklyn.core.catalog.internal.BasicBrooklynCatalog@6af14528, now
switching
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.i.BasicBrooklynCatalog [main]: Adding
manual catalog item to LocalManagementContext[E5deSfFR-xoVyTRQg]:
CatalogLocationItemDto[sample_location:0.0.1/sample_location]
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Loading
catalog Loaded:CatalogDto{name=Manual Catalog Additions,
contentsDescription=manual-additions}(not yet loaded) into
Loaded:CatalogDto{name=Rebind catalog item test,
contentsDescription=classpath://brooklyn/entity/rebind/rebind-catalog-item-test-catalog.xml}(size
1)
2016-02-24 23:34:52,285 DEBUG o.a.b.c.c.internal.CatalogDo [main]: Building
cache for Loaded:CatalogDto{name=Manual Catalog Additions,
contentsDescription=manual-additions}(not
[jira] [Commented] (BROOKLYN-206) Unreliable test: AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
[
https://issues.apache.org/jira/browse/BROOKLYN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166341#comment-15166341
]
Alex Heneveld commented on BROOKLYN-206:
likely the same as BROOKLYN-205
> Unreliable test:
> AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
> ---
>
> Key: BROOKLYN-206
> URL: https://issues.apache.org/jira/browse/BROOKLYN-206
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Stacktrace
> {code}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> {code}
> Debug log
> {code}
> 2015-12-15 15:30:17,853 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> 2015-12-15 15:30:18,096 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x}, obtaining a new location
> instance in FixedListMachineProvisioningLocation{id=HsQneYPD,
> name=FixedListMachineProvisioningLocation:HsQn} with ports [22, 8000, 8443]
> 2015-12-15 15:30:18,108 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x} on machine
> SshMachineLocation[SshMachineLocation:TM32:null@/1.1.1.1:22(id=TM32DuVH)]
> 2015-12-15 15:30:18,242 INFO Added policy
> ServerPoolMemberTrackerPolicy{name=Controller targets tracker, running=true}
> to TrackingAbstractControllerImpl{id=Zveoz16x}
> 2015-12-15 15:30:18,242 INFO Resetting
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO Updating
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO test controller reconfigure, targets []
> 2015-12-15 15:30:18,252 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> finished in 399 ms
> 2015-12-15 15:30:18,253 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> 2015-12-15 15:30:33,398 INFO succeedsEventually exceeded max attempts or
> timeout - 39 attempts lasting 15001 ms, for
> RunnableAdapter(org.apache.brooklyn.entity.proxy.AbstractControllerTest$3@186540e1)
> 2015-12-15 15:30:33,398 INFO failed succeeds-eventually, 39 attempts,
> 15001ms elapsed (rethrowing): java.lang.AssertionError: expected [true] but
> found [false]
> 2015-12-15 15:30:33,401 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> finished in 15147 ms
> java.lang.AssertionError: expected [true] but found [false]
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest$3.run(AbstractControllerTest.java:300)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1208)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:870)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:797)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertEventuallyExplicitAddressesMatch(AbstractControllerTest.java:298)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges(AbstractControllerTest.java:120)
> 2015-12-15 15:30:33,406 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
> 2015-12-15 15:30:33,417 INFO Stopping
> TrackingAbstractControllerImpl{id=Zveoz16x} in
> [SshMachineLocation[SshMachineLocation:TM32:null@1.1.1.1/1.1.1.1:22(id=TM32DuVH)]]
> 2015-12-15 15:30:33,460 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @AfterMethod
> org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
> in 55 ms
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BROOKLYN-231) Unpredictable test, deleting catalog item not guaranteed through persistence
Alex Heneveld created BROOKLYN-231:
--
Summary: Unpredictable test, deleting catalog item not guaranteed
through persistence
Key: BROOKLYN-231
URL: https://issues.apache.org/jira/browse/BROOKLYN-231
Project: Brooklyn
Issue Type: Bug
Reporter: Alex Heneveld
Observed in
https://builds.apache.org/job/brooklyn-master-build/org.apache.brooklyn$brooklyn-core/19/testReport/junit/org.apache.brooklyn.core.mgmt.rebind/RebindCatalogItemTest/testAddAndRebindAndDeleteLocation/
>From the error message it looks like the deletion is not guaranteed to be
>picked up by persistence.
Error Message
Sets differ: expected [com.example.ExampleApp:9.1.3] but got
[com.example.ExampleApp:9.1.3, sample_location:0.0.1]
Stacktrace
java.lang.AssertionError: Sets differ: expected [com.example.ExampleApp:9.1.3]
but got [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.assertEquals(Assert.java:806)
at org.testng.Assert.assertEquals(Assert.java:784)
at
org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
at
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
at
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
Standard Output
2016-02-17 01:01:11,412 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
2016-02-17 01:01:11,421 WARN Setting Application[M6UGmDSN] on-fire due to
problems when expected running, up=false, not-up-indicators:
{service.state=Application stopping}
2016-02-17 01:01:11,428 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@AfterMethod
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished
in 16 ms
2016-02-17 01:01:11,429 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" -
@BeforeMethod org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp()
2016-02-17 01:01:11,538 INFO Test class
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest persisting to
/tmp/RebindCatalogItemTest-HOPQ
2016-02-17 01:01:11,555 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
@BeforeMethod
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.setUp() finished in
127 ms
2016-02-17 01:01:11,556 INFO TESTNG INVOKING: "Surefire test" -
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
2016-02-17 01:01:11,558 WARN Legacy CatalogLoadMode LOAD_BROOKLYN_CATALOG_URL
set: applying, but this should be changed to use new CLI --catalogXxx commands
2016-02-17 01:01:11,595 INFO Rebinding app, using mementoDir
/tmp/RebindCatalogItemTest-HOPQ; object store null
2016-02-17 01:01:11,681 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
for master TvJBFrIf...
2016-02-17 01:01:11,724 INFO Rebind complete (MASTER) in 121ms: 1 app, 2
entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
2016-02-17 01:01:11,741 INFO Deleted item from catalog: sample_location:0.0.1
2016-02-17 01:01:11,749 INFO Count of incomplete tasks now 0, 0 unended; tasks
remembered are: []
2016-02-17 01:01:11,757 INFO Rebinding app, using mementoDir
/tmp/RebindCatalogItemTest-HOPQ; object store null
2016-02-17 01:01:11,797 INFO Rebinding from /tmp/RebindCatalogItemTest-HOPQ
for master fTqApBF7...
2016-02-17 01:01:11,846 INFO Rebind complete (MASTER) in 81ms: 1 app, 2
entities, 0 locations, 0 policies, 2 enrichers, 0 feeds, 2 catalog items
2016-02-17 01:01:11,885 INFO TESTNG FAILED: "Surefire test" -
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation()
finished in 328 ms
java.lang.AssertionError: Sets differ: expected [com.example.ExampleApp:9.1.3]
but got [com.example.ExampleApp:9.1.3, sample_location:0.0.1]
at
org.apache.brooklyn.core.mgmt.rebind.RebindTestFixture.assertCatalogsEqual(RebindTestFixture.java:288)
at
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.rebindAndAssertCatalogsAreEqual(RebindCatalogItemTest.java:283)
at
org.apache.brooklyn.core.mgmt.rebind.RebindCatalogItemTest.testAddAndRebindAndDeleteLocation(RebindCatalogItemTest.java:185)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-206) Unreliable test: AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
[
https://issues.apache.org/jira/browse/BROOKLYN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163903#comment-15163903
]
Alex Heneveld commented on BROOKLYN-206:
i (alex) don't understand how this is happening. probably optimistic but maybe
it is fixed. if not we'll need the debug logs to see what is happening.
i've confirmed:
* the policy is attached and active during setup, before start completes
* the child is added as a member synchronously
* the policy which is "subscribed to members" is in fact subscribed to
everything
then filtered for members, not ideal, but there shouldn't be a race in the
policy getting notices
* the handling of those events are both processed in order and look up the
current values
rather than relying on the published values; either should be sufficient to
cause the addresses to change
there was a sleep(100) marked "Ugly sleep to allow AbstractController to detect
node having been added"
from the test's addition by aled in early 2014, but can't see why that would be
necessary
> Unreliable test:
> AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges
> ---
>
> Key: BROOKLYN-206
> URL: https://issues.apache.org/jira/browse/BROOKLYN-206
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Sam Corbett
>
> Stacktrace
> {code}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> {code}
> Debug log
> {code}
> 2015-12-15 15:30:17,853 INFO TESTNG INVOKING CONFIGURATION: "Surefire test"
> - @BeforeMethod
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> 2015-12-15 15:30:18,096 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x}, obtaining a new location
> instance in FixedListMachineProvisioningLocation{id=HsQneYPD,
> name=FixedListMachineProvisioningLocation:HsQn} with ports [22, 8000, 8443]
> 2015-12-15 15:30:18,108 INFO Starting
> TrackingAbstractControllerImpl{id=Zveoz16x} on machine
> SshMachineLocation[SshMachineLocation:TM32:null@/1.1.1.1:22(id=TM32DuVH)]
> 2015-12-15 15:30:18,242 INFO Added policy
> ServerPoolMemberTrackerPolicy{name=Controller targets tracker, running=true}
> to TrackingAbstractControllerImpl{id=Zveoz16x}
> 2015-12-15 15:30:18,242 INFO Resetting
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO Updating
> TrackingAbstractControllerImpl{id=Zveoz16x}, server pool targets {}
> 2015-12-15 15:30:18,244 INFO test controller reconfigure, targets []
> 2015-12-15 15:30:18,252 INFO TESTNG PASSED CONFIGURATION: "Surefire test" -
> @BeforeMethod org.apache.brooklyn.entity.proxy.AbstractControllerTest.setUp()
> finished in 399 ms
> 2015-12-15 15:30:18,253 INFO TESTNG INVOKING: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> 2015-12-15 15:30:33,398 INFO succeedsEventually exceeded max attempts or
> timeout - 39 attempts lasting 15001 ms, for
> RunnableAdapter(org.apache.brooklyn.entity.proxy.AbstractControllerTest$3@186540e1)
> 2015-12-15 15:30:33,398 INFO failed succeeds-eventually, 39 attempts,
> 15001ms elapsed (rethrowing): java.lang.AssertionError: expected [true] but
> found [false]
> 2015-12-15 15:30:33,401 INFO TESTNG FAILED: "Surefire test" -
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.testUpdateCalledWhenChildHostnameAndPortChanges()
> finished in 15147 ms
> java.lang.AssertionError: expected [true] but found [false]
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertAddressesMatch(AbstractControllerTest.java:308)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.access$100(AbstractControllerTest.java:67)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest$3.run(AbstractControllerTest.java:300)
> at
> org.apache.brooklyn.test.Asserts$RunnableAdapter.call(Asserts.java:1208)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:870)
> at org.apache.brooklyn.test.Asserts.succeedsEventually(Asserts.java:797)
> at
> org.apache.brooklyn.entity.proxy.AbstractControllerTest.assertEventuallyExplicitAddressesMatch(AbstractControllerTest.java:298)
> at
>
[jira] [Commented] (BROOKLYN-227) Exceptions not being logged
[
https://issues.apache.org/jira/browse/BROOKLYN-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163548#comment-15163548
]
Alex Heneveld commented on BROOKLYN-227:
Agree [~aled.sage] - we should use `collapseText` when reporting to a user, and
should not suppress causes unless we are sure we don't want them
fixed in
https://github.com/ahgittin/brooklyn-server/commit/c20a725459764f10cfa5e6c9a7cee33db8de1559
in https://github.com/apache/brooklyn-server/pull/38
> Exceptions not being logged
> ---
>
> Key: BROOKLYN-227
> URL: https://issues.apache.org/jira/browse/BROOKLYN-227
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> In 0.9.0-SNAPSHOT, a couple of times now I've hit exceptions that are not
> logged anywhere within brooklyn debug log. A good example is:
> {noformat}
> 2016-02-20 22:09:00,037 DEBUG b.l.docker.DockerResolver
> [brooklyn-execmanager-dO9Ptbsx-0]: Resolving location
> 'docker:j1M7T5XG:(name="my-docker-cloud-vagrant")' with flags
> provisioner=FixedListMachineProvisioningLocation{id=DtPfBrpb,
> name=FixedListMachineProvisioningLocation:DtPf},strat
> egies=[DockerAwarePlacementStrategy(MaxContainersPlacementStrategy@j8yVexHt),
> DockerAwarePlacementStrategy(BreadthFirstPlacementStrategy@ce2SXY0W)],spec.named.name=my-docker-cloud-vagrant,spec.original=my-docker-cloud-vagrant
> 2016-02-20 22:09:00,048 WARN o.a.b.c.m.r.RebindExceptionHandlerImpl
> [brooklyn-execmanager-dO9Ptbsx-0]: Rebind: continuing after problem rebinding
> entity j1M7T5XG (DockerInfrastructureImpl{id=j1M7T5XG})
> java.lang.IllegalStateException: Cannot instantiate location
> 'LocationDefinition{id='gzuSFMac', name='my-docker-cloud-vagrant',
> spec='docker:j1M7T5XG:(name="my-docker-cloud-vagrant")',
> config={provisioner=FixedListMachineProvisioningLocation{id=DtPfBrpb,
> name=FixedListMachineProvisioningLocation:DtPf},
> strategies=[DockerAwarePlacementStrategy(MaxContainersPlacementStrategy@j8yVexHt),
> DockerAwarePlacementStrategy(BreadthFirstPlacementStrategy@ce2SXY0W)]}}'
> pointing at docker:j1M7T5XG:(name="my-docker-cloud-vagrant"):
> java.lang.NullPointerException
> at
> org.apache.brooklyn.core.location.BasicLocationRegistry.resolve(BasicLocationRegistry.java:490)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.location.BasicLocationRegistry.resolve(BasicLocationRegistry.java:459)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> brooklyn.entity.container.DockerUtils$ReloadDockerLocation.reloaded(DockerUtils.java:392)
> ~[brooklyn-clocker-docker-1.1.0-20160125.1743-p1.jar:1.1.0-20160125.1743-p1]
> at
> brooklyn.entity.container.docker.DockerInfrastructureImpl.rebind(DockerInfrastructureImpl.java:346)
> ~[brooklyn-clocker-docker-1.1.0-20160125.1743-p1.jar:1.1.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.AbstractBrooklynObjectRebindSupport.reconstruct(AbstractBrooklynObjectRebindSupport.java:69)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.reconstructEverything(RebindIteration.java:623)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.doRun(RebindIteration.java:242)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.InitialFullRebindIteration.doRun(InitialFullRebindIteration.java:69)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.run(RebindIteration.java:265)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl.rebindImpl(RebindManagerImpl.java:552)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl$3.call(RebindManagerImpl.java:502)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl$3.call(RebindManagerImpl.java:500)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:499)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
[jira] [Resolved] (BROOKLYN-227) Exceptions not being logged
[
https://issues.apache.org/jira/browse/BROOKLYN-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld resolved BROOKLYN-227.
Resolution: Fixed
> Exceptions not being logged
> ---
>
> Key: BROOKLYN-227
> URL: https://issues.apache.org/jira/browse/BROOKLYN-227
> Project: Brooklyn
> Issue Type: Bug
>Reporter: Aled Sage
>
> In 0.9.0-SNAPSHOT, a couple of times now I've hit exceptions that are not
> logged anywhere within brooklyn debug log. A good example is:
> {noformat}
> 2016-02-20 22:09:00,037 DEBUG b.l.docker.DockerResolver
> [brooklyn-execmanager-dO9Ptbsx-0]: Resolving location
> 'docker:j1M7T5XG:(name="my-docker-cloud-vagrant")' with flags
> provisioner=FixedListMachineProvisioningLocation{id=DtPfBrpb,
> name=FixedListMachineProvisioningLocation:DtPf},strat
> egies=[DockerAwarePlacementStrategy(MaxContainersPlacementStrategy@j8yVexHt),
> DockerAwarePlacementStrategy(BreadthFirstPlacementStrategy@ce2SXY0W)],spec.named.name=my-docker-cloud-vagrant,spec.original=my-docker-cloud-vagrant
> 2016-02-20 22:09:00,048 WARN o.a.b.c.m.r.RebindExceptionHandlerImpl
> [brooklyn-execmanager-dO9Ptbsx-0]: Rebind: continuing after problem rebinding
> entity j1M7T5XG (DockerInfrastructureImpl{id=j1M7T5XG})
> java.lang.IllegalStateException: Cannot instantiate location
> 'LocationDefinition{id='gzuSFMac', name='my-docker-cloud-vagrant',
> spec='docker:j1M7T5XG:(name="my-docker-cloud-vagrant")',
> config={provisioner=FixedListMachineProvisioningLocation{id=DtPfBrpb,
> name=FixedListMachineProvisioningLocation:DtPf},
> strategies=[DockerAwarePlacementStrategy(MaxContainersPlacementStrategy@j8yVexHt),
> DockerAwarePlacementStrategy(BreadthFirstPlacementStrategy@ce2SXY0W)]}}'
> pointing at docker:j1M7T5XG:(name="my-docker-cloud-vagrant"):
> java.lang.NullPointerException
> at
> org.apache.brooklyn.core.location.BasicLocationRegistry.resolve(BasicLocationRegistry.java:490)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.location.BasicLocationRegistry.resolve(BasicLocationRegistry.java:459)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> brooklyn.entity.container.DockerUtils$ReloadDockerLocation.reloaded(DockerUtils.java:392)
> ~[brooklyn-clocker-docker-1.1.0-20160125.1743-p1.jar:1.1.0-20160125.1743-p1]
> at
> brooklyn.entity.container.docker.DockerInfrastructureImpl.rebind(DockerInfrastructureImpl.java:346)
> ~[brooklyn-clocker-docker-1.1.0-20160125.1743-p1.jar:1.1.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.AbstractBrooklynObjectRebindSupport.reconstruct(AbstractBrooklynObjectRebindSupport.java:69)
> ~[brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.reconstructEverything(RebindIteration.java:623)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.doRun(RebindIteration.java:242)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.InitialFullRebindIteration.doRun(InitialFullRebindIteration.java:69)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindIteration.run(RebindIteration.java:265)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl.rebindImpl(RebindManagerImpl.java:552)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl$3.call(RebindManagerImpl.java:502)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.core.mgmt.rebind.RebindManagerImpl$3.call(RebindManagerImpl.java:500)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at
> org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:499)
> [brooklyn-core-0.9.0-20160125.1743-p1.jar:0.9.0-20160125.1743-p1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> {noformat}
> See the code change that was made in
> https://github.com/apache/brooklyn-server/commit/4cb25a42938dcc4383bd831d00841d91b400ac99
> (where I've just added a comment).
> In that particular situation, we should change it to include
[jira] [Resolved] (BROOKLYN-229) Get IllegalArgumentException by the use of the keypair parameter in a namedlocation
[
https://issues.apache.org/jira/browse/BROOKLYN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Heneveld resolved BROOKLYN-229.
Resolution: Fixed
> Get IllegalArgumentException by the use of the keypair parameter in a
> namedlocation
> ---
>
> Key: BROOKLYN-229
> URL: https://issues.apache.org/jira/browse/BROOKLYN-229
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Felix Otto
>
> For any new ec2 instance automatically a new key pair will be generated in
> AWS by the jcloud implementation. After some research we find out that it is
> possible to set the keypair in the named location of the brooklyn.properties
> file. If we set the keypair in the named location than we get the following
> error:
> log:
> {code}
> java.lang.IllegalArgumentException: no private key configured for:
> {region=eu-central-1, name=01-brooklyn}; please use
> options.overrideLoginCredentialWith(rsa_private_text)
> {code}
> brooklyn.properties:
> {code}
> brooklyn.location.named.aws-frankfurt= jclouds:aws-ec2:eu-central-1
> brooklyn.location.named.aws-frankfurt.displayName=AWS Frankfurt
> (ida-01-brooklyn)
> brooklyn.location.named.aws-frankfurt.identity=
> brooklyn.location.named.aws-frankfurt.credential=
> brooklyn.location.named.aws-frankfurt.keyPair=01-brooklyn
> brooklyn.location.named.aws-frankfurt.privateKeyFile=/home/ubuntu/.ssh/id_rsa
> brooklyn.location.named.aws-frankfurt.publicKeyFile=/home/ubuntu/.ssh/id_rsa.pub
> {code}
> This cause for this problem can be found in the class
> org.jclouds.ec2.compute.strategy.CreateKeyPairAndSecurityGroupsAsNeededAndReturnRunOptions
> line 128
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-229) Get IllegalArgumentException by the use of the keypair parameter in a namedlocation
[
https://issues.apache.org/jira/browse/BROOKLYN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15163519#comment-15163519
]
Alex Heneveld commented on BROOKLYN-229:
Thanks Felix. With your confirmation I've update the docs source [1] so others
won't have the issue you had.
[1] https://github.com/apache/brooklyn-docs/pull/19
> Get IllegalArgumentException by the use of the keypair parameter in a
> namedlocation
> ---
>
> Key: BROOKLYN-229
> URL: https://issues.apache.org/jira/browse/BROOKLYN-229
> Project: Brooklyn
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Felix Otto
>
> For any new ec2 instance automatically a new key pair will be generated in
> AWS by the jcloud implementation. After some research we find out that it is
> possible to set the keypair in the named location of the brooklyn.properties
> file. If we set the keypair in the named location than we get the following
> error:
> log:
> {code}
> java.lang.IllegalArgumentException: no private key configured for:
> {region=eu-central-1, name=01-brooklyn}; please use
> options.overrideLoginCredentialWith(rsa_private_text)
> {code}
> brooklyn.properties:
> {code}
> brooklyn.location.named.aws-frankfurt= jclouds:aws-ec2:eu-central-1
> brooklyn.location.named.aws-frankfurt.displayName=AWS Frankfurt
> (ida-01-brooklyn)
> brooklyn.location.named.aws-frankfurt.identity=
> brooklyn.location.named.aws-frankfurt.credential=
> brooklyn.location.named.aws-frankfurt.keyPair=01-brooklyn
> brooklyn.location.named.aws-frankfurt.privateKeyFile=/home/ubuntu/.ssh/id_rsa
> brooklyn.location.named.aws-frankfurt.publicKeyFile=/home/ubuntu/.ssh/id_rsa.pub
> {code}
> This cause for this problem can be found in the class
> org.jclouds.ec2.compute.strategy.CreateKeyPairAndSecurityGroupsAsNeededAndReturnRunOptions
> line 128
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BROOKLYN-221) doc site's learnmore/catalog is empty
[ https://issues.apache.org/jira/browse/BROOKLYN-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135729#comment-15135729 ] Alex Heneveld commented on BROOKLYN-221: Fixed and uploaded to site :) > doc site's learnmore/catalog is empty > - > > Key: BROOKLYN-221 > URL: https://issues.apache.org/jira/browse/BROOKLYN-221 > Project: Brooklyn > Issue Type: Documentation >Reporter: Scott Hartzel >Assignee: Alex Heneveld >Priority: Minor > > http://brooklyn.apache.org/learnmore/catalog/index.html is empty. Returns no > entities, policies or locations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BROOKLYN-221) doc site's learnmore/catalog is empty
[ https://issues.apache.org/jira/browse/BROOKLYN-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134555#comment-15134555 ] Alex Heneveld commented on BROOKLYN-221: This is possibly due to the restructuring and change in build order. I will investigate. > doc site's learnmore/catalog is empty > - > > Key: BROOKLYN-221 > URL: https://issues.apache.org/jira/browse/BROOKLYN-221 > Project: Brooklyn > Issue Type: Documentation >Reporter: Scott Hartzel >Priority: Minor > > http://brooklyn.apache.org/learnmore/catalog/index.html is empty. Returns no > entities, policies or locations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (BROOKLYN-221) doc site's learnmore/catalog is empty
[ https://issues.apache.org/jira/browse/BROOKLYN-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Heneveld reassigned BROOKLYN-221: -- Assignee: Alex Heneveld > doc site's learnmore/catalog is empty > - > > Key: BROOKLYN-221 > URL: https://issues.apache.org/jira/browse/BROOKLYN-221 > Project: Brooklyn > Issue Type: Documentation >Reporter: Scott Hartzel >Assignee: Alex Heneveld >Priority: Minor > > http://brooklyn.apache.org/learnmore/catalog/index.html is empty. Returns no > entities, policies or locations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
