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
