-
Sub-task
-
Resolution: Obsolete
-
Major
-
jboss-fuse-6.1
-
None
-
None
-
%
1. Using build 372 apply the fabric-zookeeper.zip patch
2. Migrate to the new version with the patch
3. Click on containers and you no longer see the container at all - screen is empty. Looking at the console, the container commands have disappeared as well:
JBossFuse:karaf@root> container-list
[id] [version] [connected] [profiles] [provision status]
root* 1.0 true fabric, fabric-ensemble-0000-1, jboss-fuse-full success
JBossFuse:karaf@root> con <tab tab>
config:cancel config:delete config:edit config:list
config:propappend config:propdel config:proplist config:propset
config:update context-info context-list context-start
context-stop
The log shows:
rintExtender$3 293 | 9 - org.apache.aries.blueprint.core - 1.0.1.redhat-610372 | Destroying BlueprintContainer for bundle io.fabric8.fabric-agent-commands
2014-03-24 16:24:52,001 | INFO | SessionTracker | SessionTrackerImpl | keeper.server.SessionTrackerImpl 162 | 57 - io.fabric8.fabric-zookeeper - 1.0.0.redhat-37X | SessionTrackerImpl exited loop!
I found that a timeout occurs after 5 minutes:
014-03-24 16:29:51,228 | ERROR | xFrameworkWiring | BeanRecipe | s.blueprint.container.BeanRecipe 873 | 9 - org.apache.aries.blueprint.core - 1.0.1.redhat-610372 | The blueprint bean watcher in bundle io.fabric8.fabric-agent-commands/1.0.0.redhat-372 incorrectly threw an exception from its destroy method.
org.osgi.service.blueprint.container.ServiceUnavailableException: Timeout expired when waiting for mandatory OSGi service reference: (objectClass=io.fabric8.api.FabricService)
at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:229)
at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:55)
at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:294)
at Proxyc9d6016e_1cb9_482c_b4ab_67ac29b22e51.untrackConfiguration(Unknown Source)
at io.fabric8.agent.commands.support.ProfileWatcher.stop(ProfileWatcher.java:428)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_51]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610372]
at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610372]
at org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610372]
at org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610372]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:717)[9:org.apache.aries.blueprint.core:1.0.1.
....
After this is caught, the container is back. Attached log for reference.
- relates to
-
ENTESB-1795 5 minute delay when adding/removing profiles to/from containers
-
- Closed
-
