I've opened bug 8342 against the controller to try to figure it out: https://bugs.opendaylight.org/show_bug.cgi?id=8342
--Colin On Mon, May 1, 2017 at 4:37 PM, Tom Pantelis <tompante...@gmail.com> wrote: > The ClassLoadingStrategy service is advertised by the ConfigManagerActivator > (a bundle activator). I don't see any errors logged for it. Maybe that > bundle didn't start for some reason? Or maybe the > mdsal-binding-generator-api bundle that exports the ClassLoadingStrategy > class re-installed/restarted and the previous Class instance was gone? I do > see that bundle outputted twice but not sure if that means it was > re-installed: > > 2017-05-01 10:39:11,968 | INFO | pool-2-thread-1 | FeaturesServiceImpl > | 8 - org.apache.karaf.features.core - 4.0.9 | > mvn:org.opendaylight.mdsal/mdsal-binding-generator-api/0.10.0-Carbon > mvn:org.opendaylight.mdsal/mdsal-binding-generator-api/0.10.0-Carbon > > 2017-05-01 10:39:12,339 | INFO | pool-2-thread-1 | FeaturesServiceImpl > | 8 - org.apache.karaf.features.core - 4.0.9 | > mvn:org.opendaylight.mdsal/mdsal-binding-generator-api/0.10.0-Carbon > > mvn:org.opendaylight.mdsal/mdsal-binding-generator-api/0.10.0-Carbon > > > On Mon, May 1, 2017 at 4:15 PM, Colin Dixon <co...@colindixon.com> wrote: > >> That seems to be the root of the issues with our SFT hangs. Between SFT >> hangs and the BGP test that hangs, those account for 12 of the last 16 >> failures in autorelease that we don't have fixes for. >> >> --Colin >> >> >> On Mon, May 1, 2017 at 4:12 PM, Tom Pantelis <tompante...@gmail.com> >> wrote: >> >>> yeah - saw that too: >>> >>> 2017-05-01 10:44:13,976 | ERROR | rint Extender: 1 | BlueprintContainerImpl >>> | 12 - org.apache.aries.blueprint.core - 1.7.1 | Unable to start >>> blueprint container for bundle >>> org.opendaylight.controller.sal-binding-broker-impl/1.5.0.Carbon due to >>> unresolved dependencies >>> [(objectClass=org.opendaylight.mdsal.binding.generator.api.ClassLoadingStrategy)] >>> java.util.concurrent.TimeoutException >>> at >>> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)[12:org.apache.aries.blueprint.core:1.7.1] >>> >>> >>> On Mon, May 1, 2017 at 4:11 PM, Colin Dixon <co...@colindixon.com> >>> wrote: >>> >>>> It seems like there's something wrong with who sal-binding-broker-impl >>>> comes up and doesn't get the ClassLoadingStrategy and then SFT hangs. So >>>> far, thats' the first exception that happens in every SFT hang I've looked >>>> into. >>>> >>>> Robert, TomP, any ideas what would cause this. It looks like the AAA >>>> issue we were having before, but it's not AAA. >>>> >>>> --Colin >>>> >>>> >>>> On Mon, May 1, 2017 at 4:03 PM, Colin Dixon <co...@colindixon.com> >>>> wrote: >>>> >>>>> So, Luis told me to go look at the surefire results for some of the >>>>> SFT failures and I'm finding things like this: >>>>> >>>>> = failnever job #4 = >>>>> relevant logfile: https://logs.opendaylight.org/ >>>>> releng/jenkins092/autorelease-release-failnever-carbon/4/arc >>>>> hives/nemo/nemo-features/odl-nemo-openflow-renderer/target/s >>>>> urefire-reports/org.opendaylight.odlparent.featuretest.Singl >>>>> eFeatureTest-output.txt.gz >>>>> Job: https://jenkins.opendaylight.org/releng/view/autorelease/job >>>>> /autorelease-release-failnever-carbon/4/ >>>>> == Key lines == >>>>> 2017-05-01 10:44:22,047 | ERROR | rint Extender: 2 | >>>>> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core >>>>> - 1.7.1 | Unable to start blueprint container for bundle >>>>> org.opendaylight.aaa.shiro/0.5.0.Carbon due to unresolved >>>>> dependencies [(objectClass=org.opendaylight.controller.md >>>>> .sal.binding.api.DataBroker), (objectClass=org.opendaylight. >>>>> aaa.cert.api.ICertificateManager)] >>>>> java.util.concurrent.TimeoutException >>>>> >>>>> = autorelease-carbon job #271 = >>>>> relevant logfile: https://logs.opendaylight.org/releng/jenkins092/aut >>>>> orelease-release-carbon/285/archives/bgpcep/programming/impl >>>>> /target/surefire-reports/ >>>>> job: https://jenkins.opendaylight.org/releng/view/autoreleas >>>>> e/job/autorelease-release-carbon/271/ >>>>> 2017-04-25 16:04:47,169 | ERROR | rint Extender: 2 | >>>>> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core >>>>> - 1.7.1 | Unable to start blueprint container for bundle >>>>> org.opendaylight.controller.sal-binding-broker-impl/1.5.0.Carbon due >>>>> to unresolved dependencies [(objectClass=org.opendaylight >>>>> .mdsal.binding.generator.api.ClassLoadingStrategy)] >>>>> java.util.concurrent.TimeoutException >>>>> >>>>> This looks like the AAA issue that we supposedly fixed. However it's >>>>> still cropping up in runs as recently as today. >>>>> >>>>> --Colin >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 1, 2017 at 12:45 PM, Colin Dixon <co...@colindixon.com> >>>>> wrote: >>>>> >>>>>> As a random idea, to counteract these failures, would it be a truly >>>>>> terrible idea to add all the SingleFeaturesTests to the excludes list for >>>>>> autorelease at least for now? >>>>>> >>>>>> --Colin >>>>>> >>>>>> >>>>>> On Mon, May 1, 2017 at 11:18 AM, Colin Dixon <co...@colindixon.com> >>>>>> wrote: >>>>>> >>>>>>> add: >>>>>>> * SFT for OpenDaylight :: NEMO :: OpenFlow Renderer in failnever >>>>>>> job #4 >>>>>>> >>>>>>> --Colin >>>>>>> >>>>>>> >>>>>>> On Mon, May 1, 2017 at 9:58 AM, Colin Dixon <co...@colindixon.com> >>>>>>> wrote: >>>>>>> >>>>>>>> As I'm tracking autorelease failures here: >>>>>>>> https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspH >>>>>>>> BNxKI_9XugJp-6Qbbw20Omk/edit#gid=1455372448 >>>>>>>> >>>>>>>> I'm noticing a reasonable number of hangs in SFT. Is that to be >>>>>>>> expected? Is there something we can do about it? >>>>>>>> >>>>>>>> Examples >>>>>>>> * SFT for integration features-test in autorelease-carbon job #271 >>>>>>>> * SFT for netconf SSH server in the failnever job #1 >>>>>>>> * SFT for features4-alto in the failnever job #3 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> --Colin >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
