Skip to main content
[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,

I think when there is a remote service publication, the ECF discovery service will kick in. This will cause the Zoodiscovery to start. On pure clients, the service discovery is the trigger and must therefore start before something can be discovered.

On clients, the autostart is therefore a good option. On servers it is not needed. If the autostart causes the lock, you can start the zoodiscovery at your convenience by using ahmed's tips. This will give the FW some time to settle in and will probably not cause the lock (which is a bug by the way and we should solve that if Markus' recent adjustments did not do the trick).

Regards,

Wim
 

On Mon, Jan 10, 2011 at 2:49 PM, Patrick D. <pd4ecf@xxxxxxxxxxxxxx> wrote:
Hello Ahmed,

I am already using:
-Dzoodiscovery.autoStart=true
-Dzoodiscovery.flavor=zoodiscovery.flavor.centralized=vs04

What surprised me was, that sometimes the autoStart was mandatory to get ZooDiscovery to connect, sometimes it could be omitted. It looks like distributing a service causes ZooDiscovery to connect, too. So on nodes where services were distributed removing the autoStart worked, and on pure consumers it didn't.

Sorry for the confusion. I will check out the head version of ECF and see if that fixes the problem.

Thank you for your help,
Patrick


On Mon, Jan 10, 2011 at 1:07 PM, <ahmed.aadel@xxxxxxxxxxxxxxxxxx> wrote:
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=192.1.10.9" });
 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.

[1]http://wiki.eclipse.org/Zoodiscovery


hope this helps,

Ahmed Aadel
remainsoftware.com


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.

Patrick


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

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,
Patrick

[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:
Hi,

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
message.

Regards,

Wiim

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=167784

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 http://pastebin.com/N08zrp6s
> 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:file:plugins/org.eclipse.ecf.provider.zookeeper_1.0.100.v20101029-1626.jar/"
> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
>
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top