Re: [ecf-dev] ZooDiscovery causing a BundleException on startup (and onl

[ahmed.aadel@xxxxxxxxxxxxxxxxxx]

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