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
