[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ZooDiscovery causing a BundleException on startup (and only for me, it seems)

Hi Patrick,

If system property "-Dzoodiscovery.autoStart"  (this property doesn't expect a value, it sole presence means true) is encountered, then zooDiscovery looks further for flavor                                                                                                        property such as  "-Dzoodiscovery.flavor=zoodiscovery.flavor.standalone"  then initiate and  connect. If no target flavor is found, zooDiscovery defaults to  starting a stand-alone sever on local host.                       Autostaring  is meant to ease provider initiation and connection by using system properties only. That is, what you do with properties,  can be reached by explicit calls as well, for instance:

See  full examples in [1]

IContainer z1= null;
 try {
 container = ContainerFactory.getDefault().createContainer("ecf.discovery.zoodiscovery");
 } catch(ContainerCreateException e1){
 ID target = container.getConnectNamespace().createInstance(  
 new String[] { "zoodiscovery.flavor.standalone=" });
 z1.connect(target, null);  

The take-away:
1- if  you intend to configure zooDiscovery via system properties, then you should at least set properties  -Dzoodiscovery.autoStart  and   -Dzoodiscovery.flavor (to avoid default).
2- If you intend to use it programmatically  as in [1] then you don't need setting the properties mentioned above, otherwise you'll end up, at best, having unneeded servers initiated and running.


hope this helps,

Ahmed Aadel

From: "Patrick D." <pd4ecf@xxxxxxxxxxxxxx>
To: "Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
Date: 10-01-2011 11:55
Subject: Re: [ecf-dev] ZooDiscovery causing a BundleException on startup (and only for me, it seems)

Hello again,

I have to correct myself.
"-Dzoodiscovery.autoStart=true" did cause the exception, but it does cause ZooDiscovery to connect. I'm puzzled why it works without it on my other setup at home and on three out of four machines at work.


On Mon, Jan 10, 2011 at 9:56 AM, Patrick D. <pd4ecf@xxxxxxxxxxxxxx> wrote:

I managed to resolve the issue. I was following the instructions in a post on Wim's blog [1].

The problem was the "-Dzoodiscovery.autoStart=true", which, I think, makes ZooDiscovery start its own server. At least I'm sure that at some point I had multiple servers running on a single host, because clients connected to different instances and saw different data. As I'm running my own Zookeeper servers anyways it was safe to remove the parameter.

The exception does not prevent ZooDiscovery from working, but it was still annoying me.
Thank you for your help,

[1] http://industrial-tsi-wim.blogspot.com/2010/06/helios-bloghaton-fun-with-remote.html

On Sun, Jan 9, 2011 at 1:29 PM, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:

The cause of this problem is that the start method of the activator
does not return within a reasonable amount of time. This is mostly
caused because starting Zookeeper starts other dependencies which
start their activator and so on. OSGi does not want to wait that long
and throws the exception. AFAICT this is harmless because ZK is not
really blocked. It happened to me too and I resolved it by starting
the Zookeeper bundles as late as possible.

Please try Markus' suggestion. If the problem persists please open a bug.

If you search for "timed out waiting (5000ms) for thread" there are
more. See [1] for an unrelated discussion on what can cause this




On Sat, Jan 8, 2011 at 6:47 PM, Patrick D. <
pd4ecf@xxxxxxxxxxxxxx> wrote:
> Hello ECF Team,
> I chose to use ECF as the communication framework for my thesis project. So
> far it is really working great. However I can't get rid of an exception when
> starting ZooDiscovery. It seems to happen every time, regardless of what
> other bundles are loaded and happens even if I only add the ZooDiscovery
> Bundle and its dependencies. The exception does not prevent ZooDiscovery
> from functioning. It works completely.
> To not clog the message I uploaded the log to
> and attached it. Here's an excerpt, though:
> !MESSAGE While loading class
> "org.eclipse.ecf.provider.zookeeper.node.internal.WriteRoot", thread
> "Thread[pool-1-thread-1,5,main]" timed out waiting (5000ms) for thread
> "Thread[Start Level Event Dispatcher,5,main]" to finish starting bundle
> "org.eclipse.ecf.provider.zookeeper_1.0.100.v20101029-1626 [13]". To avoid
> deadlock, thread "Thread[pool-1-thread-1,5,main]" is proceeding but
> "org.eclipse.ecf.provider.zookeeper.node.internal.WriteRoot" may not be
> fully initialized.
> !STACK 0
> org.osgi.framework.BundleException: State change in progress for bundle
> "initial@reference:
> by thread "Start Level Event Dispatcher".
> [...]
> This happens right after the start of the framework, and I have absolutely
> no idea why. I searched Google for a solution but only found an old message
> from myself with a different problem but the exception already present. This
> frustrates me a bit, because it means I'm obviously the only person that's
> getting it.
> Can you tell me what's causing this? I have done fresh installations of
> Eclipse and ECF on different PCs and worked with different, small example
> projects, but the exception occurs every time.
> Thanks in advance,
> Patrick D.

> _______________________________________________
> ecf-dev mailing list
ecf-dev mailing list


ecf-dev mailing list