[
https://issues.apache.org/activemq/browse/SM-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63404#action_63404
]
Kurt Westerfeld commented on SM-2011:
-------------------------------------
OK, it looks like this latest workaround I tried didn't solve the problem.
Here's some factors that might be part of the equation:
- we install our own feature bundle at first startup
- the service missing in question is bundled along with 2 other services
- we create 3 binding components as well, which are companions to these 3
services by the same service name (ie. external)
- the 3 binding components initialize fine
- 2 of the 3 service components initialize fine
- 1 of the 3 service components does not initialize, and there are no
messages in the logs indicating why, or what might have gone wrong
- a successful initialization path just results in all 3 of the service
components initializing
- the service that fails to register is always the first of the 3 service
components in the grouping
The 3 service initializations look like the following (all in the same spring
beans.xml file):
<cxfse:endpoint>
<cxfse:pojo>
<bean class="<impl.class.name>" />
</cxfse:pojo>
</cxfse:endpoint>
> NMR Registration Fails on Startup Intermittently
> ------------------------------------------------
>
> Key: SM-2011
> URL: https://issues.apache.org/activemq/browse/SM-2011
> Project: ServiceMix
> Issue Type: Bug
> Environment: Fuse 4.3
> Reporter: Kurt Westerfeld
> Priority: Critical
>
> We have a number of services which start when servicemix starts, based on
> servicemix-cxf-se, which publish endpoints to the NMR implicitly by using
> org.apache.servicemix.common.osgi.EndpointExporter. We are seeing the
> situation where after startup, some of our services are missing from the
> endpoint registry. We cannot see them using the admin command "nmr:list",
> and in tracking this down, have noticed that the
> org.apache.servicemix.nmr.core.EndpointRegistryImpl does not contain a
> mapping for the service. This is clearly a bug, because if we do an
> osgi:restart on the bundle containing our service the NMR will correctly
> register the endpoints.
> This is obviously causing us concern. We have worked around other
> initialization problems with our servicemix-cxf-se services related to
> generation of proxies by injecting the component registry
> (org.apache.servicemix.jbi.runtime.ComponentRegistry) to the proxy. We are
> wondering if there is a similar workaround we must perform in order to ensure
> our components do not initialize before the NMR service registry tracker is
> ready to receive them.
> Noticing a normal initialization sees this stacktrace fragment:
>
> org.apache.servicemix.nmr.core.EndpointRegistryImpl.register(org.apache.servicemix.nmr.api.Endpoint,
> java.util.Map<java.lang.String,?>) line: 115
>
> org.apache.servicemix.nmr.core.EndpointRegistryImpl.register(java.lang.Object,
> java.util.Map) line: 49
>
> org.apache.servicemix.nmr.osgi.OsgiServiceRegistryTracker<T>.addingService(org.osgi.framework.ServiceReference)
> line: 78
> So, it seems that the
> org.apache.servicemix.nmr.osgi.OsgiServiceRegistryTracker listener must be
> getting initialized *after* our own bundle in this case. Since this class
> registers a service tracker, it is my bet that it is not tracking services
> before our service's endpoint exporter has started running. In another odd
> twist, the main culprit in our use case exports 3 services, and only one of
> them seems to be missing.
> The complexity of getting our services to start properly and reliably has
> been the most significant issue facing us in our port from servicemix 3 to 4.
> We'd appreciate some help and/or fixes to get us moving in the right
> direction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
