[
https://issues.apache.org/activemq/browse/SM-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63416#action_63416
]
Kurt Westerfeld commented on SM-2011:
-------------------------------------
Chris, on your request here is what I did.
I have a "broken" scenario where my cxf-se components are deployed from one
spring artifact. It turns out breaking this scenario into three spring files
does not help either, so at least it consistently breaks. I mistakenly
thought this change fixed things, but in creating this controlled test
scenario it's clear that it does not (read below).
Using this scenario, I'm able to reproduce my problem about 1 times in 10
starts.
I wrote a small service that detects the problem by querying the JBI/NMR
registry to
find the 3 services in question, and when it finds all three it simply does a
System.exit(). This "seeker" service has to be careful on system startup to
try multiple times after sleeping, to be sure that it indeed cannot contact all
three of these services. The reason for this is, for my test scenario I would
like this
to run in a loop, where the system is started, and if it starts OK, just
restart.
To test your single-processor affinity theory, I am using Windows so I had to
use a slightly different technique than your suggestion. But I validated that
on startup the java executable is indeed running in single CPU affinity (I use
sysinternals process explorer for this validation). For those that might be
interested in how to do this, you can download an executable utility that marks
an executable as having a specific affinity mask here:
http://www.robpol86.com/index.php/ImageCFG.
I simply copyied java.exe to another executable file and launch the marked one
instead of the stock java.exe.
So, all this runs, and I can reproduce the problem with both multi-processor
startup and single-processor startup. So, that theory goes out the window.
I have the ability to test different theories on why this failure occurs if you
have
any other ideas.
> 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.
