[
https://issues.apache.org/activemq/browse/SM-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63434#action_63434
]
Kurt Westerfeld commented on SM-2011:
-------------------------------------
Chris & Freeman,
I stumbled onto a fix for this issue, on a hunch I had by looking at how the
endpoint exporter does it's thing. Basically, endpoint exporter queries the
application context for a list of endpoints, and that process seems to return
the list with a set of services that all have manufactured identifiers. For
example, each service looks something like "...CxfEndpoint#0",
"...CxfEndpoint#1", etc.
My thinking was that if I declared my cxfse:endpoint with ids, the problem
would go away. And sure enough, it does. Now, to me this looks like a bug in
spring, but I don't even see how the application context is manufactured from
more than one thread. If it is, then that's a problem because it doesn't seem
thread-safe. If it isn't, well, I have no explanation.
To sum up, if I declare my services something like this:
<cxfse:endpoint id="service1">
<cxfse:pojo>
<bean class="com.example.service.Service1" />
</cxfse:pojo>
</cxfse:endpoint>
<cxfse:endpoint id="service2">
<cxfse:pojo>
<bean class="com.example.service.Service2" />
</cxfse:pojo>
</cxfse:endpoint>
Then they always are constructed and found on the bus. Without an id
declaration, I get random and silent failures on init....basically some of the
services never get constructed.
I did create an example service and the "seeker" service that looks for the
services to reproduce this. I can see about whittling that down some to
provide you with a testcase, unless you don't need it. Even with this
testcase, it does require several start/clean/restarts before the problem ever
shows up.
> 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.
