[
https://issues.apache.org/activemq/browse/SM-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63403#action_63403
]
Kurt Westerfeld commented on SM-2011:
-------------------------------------
I thought about it, and I can't see how I'd create a testcase. My issue
involves start/stop/start/stop with the servicemix container, and I believe the
issue to be that my box, having 8 cores, can start initialization of some of
the OSGi bundles that need to register with the NMR and it hasn't finished
installing it's endpoint tracker listener.
If you do an ls on:
[ 82] [Active ] [Created ] [ ] [ 60] Apache ServiceMix NMR
OSGi (1.3.0.fuse-01-00)
This service produces the NMR to the registry very early in its initialization:
osgi.service.blueprint.compname = servicemix
objectClass = org.apache.servicemix.nmr.api.NMR
service.id = 178
I had a look at its blueprint file here:
http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/nmr/osgi/src/main/resources/OSGI-INF/blueprint/servicemix-nmr.xml
And it looks to me that service registration of the NMR occurs independent of
the OsgiServiceRegistryTracker, and I don't know enough about blueprint to say
whether serivce registrations happen inline with bean creation. I can say
this: based on the fact that we're still having the problem sporadically, I
really don't think the NMR injection would guarantee that the service tracker
that OsgiServiceRegistryTracker installs is active.
So, back to workaound. We currently inject a reference to the NMR to hope that
the OsgiServiceRegistryTracker is installed. This doesn't work. So, the only
thing else I can try is perhaps make our services depend on the servicemix
components themselves, this way:
<osgi:reference
id="servicemix-cxf-bc-component"
interface="javax.jbi.component.Component"
filter="(NAME=servicemix-cxf-bc)"
cardinality="1..1" />
Which is ugly, and it has to be done on each of our bundles that create a
service or binding. We have about 40 of these, so it's not that big a deal. I
do think, however, an initialization problem like this should/could be handled
by a well-known technique.
> 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.
