[
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)
|
Hello,
Markus' adjustments fixed the problem and the exception does no longer happen with a recent build from the repository.
Using an unreleased version might be a bit problematic for me, but with your tips I'm sure that I will find a way around it.
Thanks for your help everybody,
Patrick
On Mon, Jan 10, 2011 at 4:26 PM, Wim Jongman
<wim.jongman@xxxxxxxxx> wrote:
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:
| |
| 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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
