You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Ronny Bräunlich <r....@gmail.com> on 2015/01/22 18:27:35 UTC
Problem with Cellar and ManagedServiceFactories
Hi everyone,
I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
I have two Karaf instances running. On both I installed Cellar and this simple project https://github.com/rbraeunlich/karaf-managed-service-factory-example
After setting config.listener = true on both and removing service.factoryPid from the config.excluded.properties I dropped a config file into the etc/ directory.
Then I could see the factory on the first Karaf instance getting called with the properties roughly every 100ms.
Debugging the Karaf couldn’t show me the source of the problem. I suggest the Karaf updates itself and therefore calls the update() method all the time.
The second instance didn’t make a move all the time.
Does anyone have a clue?
Cheers,
Ronny
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
The ManagedServiceFactory comes from a bundle right ?
It's a bundle containing a service implementing ManagedServiceFactory.
So, you have to sync the bundle with Cellar: you will have the factory
on the nodes, and the sync on the config created by the factory.
You see what I mean ?
Regards
JB
On 01/22/2015 07:36 PM, Ronny Bräunlich wrote:
> Hi Jean-Baptiste,
>
> I’m sure you didn’t exclude it just for fun :D
>
> According to your example, node1 shares the configuration (without factoryPid) with node2. Does node2 generate its own factoryPid then? Shouldn’t this result in both ManagedFactories on both nodes creating a service?
> I tried this before and it didn’t work.
>
> Could I avoid this whole problem by providing the configuration via a bundle?
>
> Cheers,
> Ronny
>
> Am 22.01.2015 um 19:19 schrieb Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
> Just one thing: even if factoryPid property is excluded, all other properties are sync (so basically all the config). Only the factoryPid is local to the node.
>
> Let me explain:
> - you have two nodes: node1 and node2 will have the config resulting from the factory. factoryPid on config on node1 will be 231312867431cdqs23 and on node2 will be 23131289SDSZé& (for instance ;)). But the config themselves will be aligned/sync by Cellar.
>
> So, you can have your factory on each node, and the config created by the factory sync.
>
> Do you see what I mean ?
>
> I didn't excluded factoryPid property just for fun ;)
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
>> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
>> I have two Karaf instances running. On both I installed Cellar and this
>> simple project
>> https://github.com/rbraeunlich/karaf-managed-service-factory-example
>> After setting config.listener = true on both and removing
>> service.factoryPid from the config.excluded.properties I dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf instance getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the problem. I
>> suggest the Karaf updates itself and therefore calls the update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, do you use etc/*.cfg file or config:* commands to create the
config files ?
On 01/22/2015 07:36 PM, Ronny Bräunlich wrote:
> Hi Jean-Baptiste,
>
> I’m sure you didn’t exclude it just for fun :D
>
> According to your example, node1 shares the configuration (without factoryPid) with node2. Does node2 generate its own factoryPid then? Shouldn’t this result in both ManagedFactories on both nodes creating a service?
> I tried this before and it didn’t work.
>
> Could I avoid this whole problem by providing the configuration via a bundle?
>
> Cheers,
> Ronny
>
> Am 22.01.2015 um 19:19 schrieb Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
> Just one thing: even if factoryPid property is excluded, all other properties are sync (so basically all the config). Only the factoryPid is local to the node.
>
> Let me explain:
> - you have two nodes: node1 and node2 will have the config resulting from the factory. factoryPid on config on node1 will be 231312867431cdqs23 and on node2 will be 23131289SDSZé& (for instance ;)). But the config themselves will be aligned/sync by Cellar.
>
> So, you can have your factory on each node, and the config created by the factory sync.
>
> Do you see what I mean ?
>
> I didn't excluded factoryPid property just for fun ;)
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
>> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
>> I have two Karaf instances running. On both I installed Cellar and this
>> simple project
>> https://github.com/rbraeunlich/karaf-managed-service-factory-example
>> After setting config.listener = true on both and removing
>> service.factoryPid from the config.excluded.properties I dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf instance getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the problem. I
>> suggest the Karaf updates itself and therefore calls the update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Ronny Bräunlich <r....@gmail.com>.
Hi Jean-Baptiste,
I’m sure you didn’t exclude it just for fun :D
According to your example, node1 shares the configuration (without factoryPid) with node2. Does node2 generate its own factoryPid then? Shouldn’t this result in both ManagedFactories on both nodes creating a service?
I tried this before and it didn’t work.
Could I avoid this whole problem by providing the configuration via a bundle?
Cheers,
Ronny
Am 22.01.2015 um 19:19 schrieb Jean-Baptiste Onofré <jb...@nanthrax.net>:
Just one thing: even if factoryPid property is excluded, all other properties are sync (so basically all the config). Only the factoryPid is local to the node.
Let me explain:
- you have two nodes: node1 and node2 will have the config resulting from the factory. factoryPid on config on node1 will be 231312867431cdqs23 and on node2 will be 23131289SDSZé& (for instance ;)). But the config themselves will be aligned/sync by Cellar.
So, you can have your factory on each node, and the config created by the factory sync.
Do you see what I mean ?
I didn't excluded factoryPid property just for fun ;)
Regards
JB
On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
> I have two Karaf instances running. On both I installed Cellar and this
> simple project
> https://github.com/rbraeunlich/karaf-managed-service-factory-example
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the problem. I
> suggest the Karaf updates itself and therefore calls the update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Just one thing: even if factoryPid property is excluded, all other
properties are sync (so basically all the config). Only the factoryPid
is local to the node.
Let me explain:
- you have two nodes: node1 and node2 will have the config resulting
from the factory. factoryPid on config on node1 will be
231312867431cdqs23 and on node2 will be 23131289SDSZé& (for instance
;)). But the config themselves will be aligned/sync by Cellar.
So, you can have your factory on each node, and the config created by
the factory sync.
Do you see what I mean ?
I didn't excluded factoryPid property just for fun ;)
Regards
JB
On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
> I have two Karaf instances running. On both I installed Cellar and this
> simple project
> https://github.com/rbraeunlich/karaf-managed-service-factory-example
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the problem. I
> suggest the Karaf updates itself and therefore calls the update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ronny,
I guess it's because you enabled the synchronizer.
I will take a look tonight (it's cast in Blueprint). I bet it doesn't
occur with listener (as it's the recommended configuration and the one
that I tested by default).
I keep you posted.
Regards
JB
On 01/27/2015 06:41 PM, Ronny Bräunlich wrote:
> Hi Jean-Baptiste,
>
> the configuration you suggested doesn’t work.
> The factory on node2 doesn’t make a move. But I can see this in the log:
>
> 2015-01-27 18:39:10,582 | WARN | r.IO.thread-in-1 | ReadHandler
> | 66 - com.hazelcast - 3.3.4 | [192.168.0.125]:5702
> [cellar] [3.3.4] hz._hzInstance_1_cellar.IO.thread-in-1 Closing socket
> to endpoint Address[192.168.0.125]:5703, Cause:java.io.EOFException:
> Remote socket closed!
>
> 2015-01-27 18:39:10,592 | ERROR | FelixStartLevel |
> BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core
> - 1.4.1 | Unable to start blueprint container for bundle
> org.apache.karaf.cellar.hazelcast
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:299)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:239)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:372)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:185)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2092)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
> Caused by:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
> at
> org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.call(ReferenceListRecipe.java:211)
> at Proxy7b861b7c_07b4_4f14_9b29_85f68cd989a5.getType(Unknown Source)
> at
> org.apache.karaf.cellar.core.event.EventHandlerServiceRegistry.bind(EventHandlerServiceRegistry.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:574)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:556)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:451)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe.track(ReferenceListRecipe.java:134)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:368)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:347)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:192)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 19 more
> Caused by: java.lang.ClassCastException:
> Proxydd524705_c712_4fa1_8eca_0b3c619efca8 cannot be cast to
> org.apache.karaf.cellar.core.Synchronizer
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:403)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:427)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.init(HazelcastGroupManager.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 70 more
>
> It happened the first time after I wanted to start the factory on node
> two and stays that way even after restart.
>
> Cheers,
> Ronny
>
>
> Am 23.01.2015 um 08:07 schrieb Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Hi Ronny,
>
> As you use cfg file in etc folder, having:
>
> - config.listener=true
> - and service.factoryPid in the excluded properties
>
> should work. I mean the -1.cfg should be sync on both node.
>
> Correct ?
>
> Regards
> JB
>
> On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
>> Hi Achim, Hi Jean-Baptiste,
>>
>> that was a lot of input for me.
>> Let me start with your questions:
>>
>> >The ManagedServiceFactory comes from a bundle right ?
>> >It's a bundle containing a service implementing ManagedServiceFactory.
>>
>> Right!
>>
>> >So, you have to sync the bundle with Cellar: you will have the factory
>> on the nodes, and the sync on the config created by the factory.
>> >You see what I mean ?
>>
>> I am not sure what you mean. Synchronising the bundle will lead to a
>> factory on each node, right. But what do you mean with "the sync on the
>> config created by the factory"? Do you mean the actual file or the object?
>>
>> >By the way, do you use etc/*.cfg file or config:* commands to create
>> the config files ?
>>
>> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>>
>> >Sometime I think a management server isn't always the worst idea when
>> configuring a cluster.
>>
>> No objections ;)
>>
>> Cheers,
>> Ronny
>>
>> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <ma...@nanthrax.net>>:
>>
>> Anyway, honestly, I don't see a huge issue just by excluding
>> factoryPid and sync the PID. It's not perfect, but it works fine if
>> the file are present in the etc folder.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>>
>> JB, no problem at all.
>> My first idea to use a UUID made of the nodeID and the
>> factoryPid, does
>> have some dangers though.
>> If someone adds this configuration on two nodes it is
>> duplicated. But
>> one has to die one death ;)
>>
>> Sometime I think a management server isn't always the worst idea
>> when
>> configuring a cluster.
>>
>> regards, Achim
>>
>>
>>
>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>> By the way, thanks Achim again for the discussion ;)
>>
>>
>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>
>> In order to manage service factory in a better way, I
>> can implement
>> something similar to fileinstall: a specific property like
>> karaf.cellar.factoryPid to know where the factory comes
>> from.
>>
>> It's the way that fileinstall manage each *.cfg file
>> (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar
>> 3.0.1-SNAPSHOT
>> (built from
>> commit
>> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
>> think I found a
>> bug.
>> I have two Karaf instances running. On both I
>> installed
>> Cellar and this
>> simple project
>> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>>
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
>> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
>> After setting config.listener = true on both and
>> removing
>> service.factoryPid from the
>> config.excluded.properties I
>> dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf
>> instance
>> getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the
>> problem. I
>> suggest the Karaf updates itself and therefore
>> calls the
>> update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/__>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Oh by the way: my tests were with Karaf 3.0.2 and Cellar 3.0.1.
Regards
JB
On 01/27/2015 06:41 PM, Ronny Bräunlich wrote:
> Hi Jean-Baptiste,
>
> the configuration you suggested doesn’t work.
> The factory on node2 doesn’t make a move. But I can see this in the log:
>
> 2015-01-27 18:39:10,582 | WARN | r.IO.thread-in-1 | ReadHandler
> | 66 - com.hazelcast - 3.3.4 | [192.168.0.125]:5702
> [cellar] [3.3.4] hz._hzInstance_1_cellar.IO.thread-in-1 Closing socket
> to endpoint Address[192.168.0.125]:5703, Cause:java.io.EOFException:
> Remote socket closed!
>
> 2015-01-27 18:39:10,592 | ERROR | FelixStartLevel |
> BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core
> - 1.4.1 | Unable to start blueprint container for bundle
> org.apache.karaf.cellar.hazelcast
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:299)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:239)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:372)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:185)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2092)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
> Caused by:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
> at
> org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.call(ReferenceListRecipe.java:211)
> at Proxy7b861b7c_07b4_4f14_9b29_85f68cd989a5.getType(Unknown Source)
> at
> org.apache.karaf.cellar.core.event.EventHandlerServiceRegistry.bind(EventHandlerServiceRegistry.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:574)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:556)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:451)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe.track(ReferenceListRecipe.java:134)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:368)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:347)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:192)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 19 more
> Caused by: java.lang.ClassCastException:
> Proxydd524705_c712_4fa1_8eca_0b3c619efca8 cannot be cast to
> org.apache.karaf.cellar.core.Synchronizer
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:403)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:427)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.init(HazelcastGroupManager.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 70 more
>
> It happened the first time after I wanted to start the factory on node
> two and stays that way even after restart.
>
> Cheers,
> Ronny
>
>
> Am 23.01.2015 um 08:07 schrieb Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Hi Ronny,
>
> As you use cfg file in etc folder, having:
>
> - config.listener=true
> - and service.factoryPid in the excluded properties
>
> should work. I mean the -1.cfg should be sync on both node.
>
> Correct ?
>
> Regards
> JB
>
> On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
>> Hi Achim, Hi Jean-Baptiste,
>>
>> that was a lot of input for me.
>> Let me start with your questions:
>>
>> >The ManagedServiceFactory comes from a bundle right ?
>> >It's a bundle containing a service implementing ManagedServiceFactory.
>>
>> Right!
>>
>> >So, you have to sync the bundle with Cellar: you will have the factory
>> on the nodes, and the sync on the config created by the factory.
>> >You see what I mean ?
>>
>> I am not sure what you mean. Synchronising the bundle will lead to a
>> factory on each node, right. But what do you mean with "the sync on the
>> config created by the factory"? Do you mean the actual file or the object?
>>
>> >By the way, do you use etc/*.cfg file or config:* commands to create
>> the config files ?
>>
>> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>>
>> >Sometime I think a management server isn't always the worst idea when
>> configuring a cluster.
>>
>> No objections ;)
>>
>> Cheers,
>> Ronny
>>
>> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <ma...@nanthrax.net>>:
>>
>> Anyway, honestly, I don't see a huge issue just by excluding
>> factoryPid and sync the PID. It's not perfect, but it works fine if
>> the file are present in the etc folder.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>>
>> JB, no problem at all.
>> My first idea to use a UUID made of the nodeID and the
>> factoryPid, does
>> have some dangers though.
>> If someone adds this configuration on two nodes it is
>> duplicated. But
>> one has to die one death ;)
>>
>> Sometime I think a management server isn't always the worst idea
>> when
>> configuring a cluster.
>>
>> regards, Achim
>>
>>
>>
>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>> By the way, thanks Achim again for the discussion ;)
>>
>>
>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>
>> In order to manage service factory in a better way, I
>> can implement
>> something similar to fileinstall: a specific property like
>> karaf.cellar.factoryPid to know where the factory comes
>> from.
>>
>> It's the way that fileinstall manage each *.cfg file
>> (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar
>> 3.0.1-SNAPSHOT
>> (built from
>> commit
>> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
>> think I found a
>> bug.
>> I have two Karaf instances running. On both I
>> installed
>> Cellar and this
>> simple project
>> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>>
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
>> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
>> After setting config.listener = true on both and
>> removing
>> service.factoryPid from the
>> config.excluded.properties I
>> dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf
>> instance
>> getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the
>> problem. I
>> suggest the Karaf updates itself and therefore
>> calls the
>> update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/__>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Maybe I found the cause (if you restart a node). Let me try.
Regards
JB
On 01/27/2015 08:56 PM, Jean-Baptiste Onofré wrote:
> Hi Ronny,
>
> I'm not able to reproduce your issue.
>
> Here's what I did:
> - I created two nodes
> - I installed Cellar on both nodes with config.listener=true
> - On node1, in the etc folder, I created my.config.cfg: the config is on
> both node
> - On node1, in the etc folder, I created my.config-1.cfg (as a factory
> one). I can see:
> Pid: my.config.9b4dac9a-12d9-44ab-a3d5-be139d582529
> service.pid = my.config.9b4dac9a-12d9-44ab-a3d5-be139d582529
> This config is present on both node.
>
> Can you try to remove the data folder and try again ?
> What I propose to you:
> - cleanup the data folder
> - fully install Cellar on node1
> - when done, install Cellar on node2
>
> Thanks,
> Regards
> JB
>
> On 01/27/2015 06:41 PM, Ronny Bräunlich wrote:
>> Hi Jean-Baptiste,
>>
>> the configuration you suggested doesn’t work.
>> The factory on node2 doesn’t make a move. But I can see this in the log:
>>
>> 2015-01-27 18:39:10,582 | WARN | r.IO.thread-in-1 | ReadHandler
>> | 66 - com.hazelcast - 3.3.4 | [192.168.0.125]:5702
>> [cellar] [3.3.4] hz._hzInstance_1_cellar.IO.thread-in-1 Closing socket
>> to endpoint Address[192.168.0.125]:5703, Cause:java.io.EOFException:
>> Remote socket closed!
>>
>> 2015-01-27 18:39:10,592 | ERROR | FelixStartLevel |
>> BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core
>> - 1.4.1 | Unable to start blueprint container for bundle
>> org.apache.karaf.cellar.hazelcast
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> Unable to initialize bean groupManager
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:299)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:239)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:372)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:185)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[9:org.apache.aries.util:1.1.0]
>>
>> at
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[9:org.apache.aries.util:1.1.0]
>>
>> at
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[9:org.apache.aries.util:1.1.0]
>>
>> at
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[9:org.apache.aries.util:1.1.0]
>>
>> at
>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[9:org.apache.aries.util:1.1.0]
>>
>> at
>> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.Felix.startBundle(Felix.java:2092)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
>> Caused by:
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> Unable to initialize bean groupManager
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>>
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
>>
>> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
>>
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
>>
>> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)
>>
>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
>>
>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
>>
>> at
>> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
>>
>> at
>> org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.call(ReferenceListRecipe.java:211)
>>
>> at Proxy7b861b7c_07b4_4f14_9b29_85f68cd989a5.getType(Unknown Source)
>> at
>> org.apache.karaf.cellar.core.event.EventHandlerServiceRegistry.bind(EventHandlerServiceRegistry.java:42)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
>>
>> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
>> at
>> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:574)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:556)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:451)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ReferenceListRecipe.track(ReferenceListRecipe.java:134)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:368)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:347)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)[org.apache.felix.framework-4.2.1.jar:]
>>
>> at
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:192)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> ... 19 more
>> Caused by: java.lang.ClassCastException:
>> Proxydd524705_c712_4fa1_8eca_0b3c619efca8 cannot be cast to
>> org.apache.karaf.cellar.core.Synchronizer
>> at
>> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:403)
>>
>> at
>> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:427)
>>
>> at
>> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.init(HazelcastGroupManager.java:101)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
>>
>> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
>> at
>> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> at
>> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[15:org.apache.aries.blueprint.core:1.4.1]
>>
>> ... 70 more
>>
>> It happened the first time after I wanted to start the factory on node
>> two and stays that way even after restart.
>>
>> Cheers,
>> Ronny
>>
>>
>> Am 23.01.2015 um 08:07 schrieb Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> Hi Ronny,
>>
>> As you use cfg file in etc folder, having:
>>
>> - config.listener=true
>> - and service.factoryPid in the excluded properties
>>
>> should work. I mean the -1.cfg should be sync on both node.
>>
>> Correct ?
>>
>> Regards
>> JB
>>
>> On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
>>> Hi Achim, Hi Jean-Baptiste,
>>>
>>> that was a lot of input for me.
>>> Let me start with your questions:
>>>
>>> >The ManagedServiceFactory comes from a bundle right ?
>>> >It's a bundle containing a service implementing ManagedServiceFactory.
>>>
>>> Right!
>>>
>>> >So, you have to sync the bundle with Cellar: you will have the factory
>>> on the nodes, and the sync on the config created by the factory.
>>> >You see what I mean ?
>>>
>>> I am not sure what you mean. Synchronising the bundle will lead to a
>>> factory on each node, right. But what do you mean with "the sync on the
>>> config created by the factory"? Do you mean the actual file or the
>>> object?
>>>
>>> >By the way, do you use etc/*.cfg file or config:* commands to create
>>> the config files ?
>>>
>>> I used a .cfg file. As you taught me its name is the Factory PID
>>> "-1.cfg".
>>>
>>> >Sometime I think a management server isn't always the worst idea when
>>> configuring a cluster.
>>>
>>> No objections ;)
>>>
>>> Cheers,
>>> Ronny
>>>
>>> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>>> <ma...@nanthrax.net>
>>> <ma...@nanthrax.net>>:
>>>
>>> Anyway, honestly, I don't see a huge issue just by excluding
>>> factoryPid and sync the PID. It's not perfect, but it works fine if
>>> the file are present in the etc folder.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>>>
>>> JB, no problem at all.
>>> My first idea to use a UUID made of the nodeID and the
>>> factoryPid, does
>>> have some dangers though.
>>> If someone adds this configuration on two nodes it is
>>> duplicated. But
>>> one has to die one death ;)
>>>
>>> Sometime I think a management server isn't always the worst idea
>>> when
>>> configuring a cluster.
>>>
>>> regards, Achim
>>>
>>>
>>>
>>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré
>>> <jb@nanthrax.net <ma...@nanthrax.net>
>>> <ma...@nanthrax.net>
>>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>>
>>> By the way, thanks Achim again for the discussion ;)
>>>
>>>
>>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>>
>>> In order to manage service factory in a better way, I
>>> can implement
>>> something similar to fileinstall: a specific property
>>> like
>>> karaf.cellar.factoryPid to know where the factory comes
>>> from.
>>>
>>> It's the way that fileinstall manage each *.cfg file
>>> (adding the
>>> felix.fileinstall.filename property).
>>>
>>> Let me dig around that and improve this.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>>
>>> Hi everyone,
>>>
>>> I am using Apache Karaf 3.0.2 and Cellar
>>> 3.0.1-SNAPSHOT
>>> (built from
>>> commit
>>> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
>>> think I found a
>>> bug.
>>> I have two Karaf instances running. On both I
>>> installed
>>> Cellar and this
>>> simple project
>>> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
>>>
>>>
>>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>>>
>>>
>>>
>>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
>>>
>>>
>>> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
>>> After setting config.listener = true on both and
>>> removing
>>> service.factoryPid from the
>>> config.excluded.properties I
>>> dropped a
>>> config file into the etc/ directory.
>>> Then I could see the factory on the first Karaf
>>> instance
>>> getting called
>>> with the properties roughly every 100ms.
>>> Debugging the Karaf couldn’t show me the source
>>> of the
>>> problem. I
>>> suggest the Karaf updates itself and therefore
>>> calls the
>>> update() method
>>> all the time.
>>> The second instance didn’t make a move all the time.
>>>
>>> Does anyone have a clue?
>>>
>>> Cheers,
>>> Ronny
>>>
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> <ma...@apache.org>
>>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
>>> & Project Lead
>>> blog <http://notizblog.nierbeck.de/__>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> <ma...@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ronny,
I'm not able to reproduce your issue.
Here's what I did:
- I created two nodes
- I installed Cellar on both nodes with config.listener=true
- On node1, in the etc folder, I created my.config.cfg: the config is on
both node
- On node1, in the etc folder, I created my.config-1.cfg (as a factory
one). I can see:
Pid: my.config.9b4dac9a-12d9-44ab-a3d5-be139d582529
service.pid = my.config.9b4dac9a-12d9-44ab-a3d5-be139d582529
This config is present on both node.
Can you try to remove the data folder and try again ?
What I propose to you:
- cleanup the data folder
- fully install Cellar on node1
- when done, install Cellar on node2
Thanks,
Regards
JB
On 01/27/2015 06:41 PM, Ronny Bräunlich wrote:
> Hi Jean-Baptiste,
>
> the configuration you suggested doesn’t work.
> The factory on node2 doesn’t make a move. But I can see this in the log:
>
> 2015-01-27 18:39:10,582 | WARN | r.IO.thread-in-1 | ReadHandler
> | 66 - com.hazelcast - 3.3.4 | [192.168.0.125]:5702
> [cellar] [3.3.4] hz._hzInstance_1_cellar.IO.thread-in-1 Closing socket
> to endpoint Address[192.168.0.125]:5703, Cause:java.io.EOFException:
> Remote socket closed!
>
> 2015-01-27 18:39:10,592 | ERROR | FelixStartLevel |
> BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core
> - 1.4.1 | Unable to start blueprint container for bundle
> org.apache.karaf.cellar.hazelcast
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:299)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:239)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:372)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:185)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[9:org.apache.aries.util:1.1.0]
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2092)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
> at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
> Caused by:
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Unable to initialize bean groupManager
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
> at
> org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.call(ReferenceListRecipe.java:211)
> at Proxy7b861b7c_07b4_4f14_9b29_85f68cd989a5.getType(Unknown Source)
> at
> org.apache.karaf.cellar.core.event.EventHandlerServiceRegistry.bind(EventHandlerServiceRegistry.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:574)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:556)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:451)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ReferenceListRecipe.track(ReferenceListRecipe.java:134)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:368)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:347)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)[org.apache.felix.framework-4.2.1.jar:]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:192)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 19 more
> Caused by: java.lang.ClassCastException:
> Proxydd524705_c712_4fa1_8eca_0b3c619efca8 cannot be cast to
> org.apache.karaf.cellar.core.Synchronizer
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:403)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:427)
> at
> org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.init(HazelcastGroupManager.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
> at
> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[15:org.apache.aries.blueprint.core:1.4.1]
> ... 70 more
>
> It happened the first time after I wanted to start the factory on node
> two and stays that way even after restart.
>
> Cheers,
> Ronny
>
>
> Am 23.01.2015 um 08:07 schrieb Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Hi Ronny,
>
> As you use cfg file in etc folder, having:
>
> - config.listener=true
> - and service.factoryPid in the excluded properties
>
> should work. I mean the -1.cfg should be sync on both node.
>
> Correct ?
>
> Regards
> JB
>
> On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
>> Hi Achim, Hi Jean-Baptiste,
>>
>> that was a lot of input for me.
>> Let me start with your questions:
>>
>> >The ManagedServiceFactory comes from a bundle right ?
>> >It's a bundle containing a service implementing ManagedServiceFactory.
>>
>> Right!
>>
>> >So, you have to sync the bundle with Cellar: you will have the factory
>> on the nodes, and the sync on the config created by the factory.
>> >You see what I mean ?
>>
>> I am not sure what you mean. Synchronising the bundle will lead to a
>> factory on each node, right. But what do you mean with "the sync on the
>> config created by the factory"? Do you mean the actual file or the object?
>>
>> >By the way, do you use etc/*.cfg file or config:* commands to create
>> the config files ?
>>
>> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>>
>> >Sometime I think a management server isn't always the worst idea when
>> configuring a cluster.
>>
>> No objections ;)
>>
>> Cheers,
>> Ronny
>>
>> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <ma...@nanthrax.net>>:
>>
>> Anyway, honestly, I don't see a huge issue just by excluding
>> factoryPid and sync the PID. It's not perfect, but it works fine if
>> the file are present in the etc folder.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>>
>> JB, no problem at all.
>> My first idea to use a UUID made of the nodeID and the
>> factoryPid, does
>> have some dangers though.
>> If someone adds this configuration on two nodes it is
>> duplicated. But
>> one has to die one death ;)
>>
>> Sometime I think a management server isn't always the worst idea
>> when
>> configuring a cluster.
>>
>> regards, Achim
>>
>>
>>
>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>> By the way, thanks Achim again for the discussion ;)
>>
>>
>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>
>> In order to manage service factory in a better way, I
>> can implement
>> something similar to fileinstall: a specific property like
>> karaf.cellar.factoryPid to know where the factory comes
>> from.
>>
>> It's the way that fileinstall manage each *.cfg file
>> (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar
>> 3.0.1-SNAPSHOT
>> (built from
>> commit
>> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
>> think I found a
>> bug.
>> I have two Karaf instances running. On both I
>> installed
>> Cellar and this
>> simple project
>> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>>
>> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
>> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
>> After setting config.listener = true on both and
>> removing
>> service.factoryPid from the
>> config.excluded.properties I
>> dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf
>> instance
>> getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the
>> problem. I
>> suggest the Karaf updates itself and therefore
>> calls the
>> update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/__>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Ronny Bräunlich <r....@gmail.com>.
Hi Jean-Baptiste,
the configuration you suggested doesn’t work.
The factory on node2 doesn’t make a move. But I can see this in the log:
2015-01-27 18:39:10,582 | WARN | r.IO.thread-in-1 | ReadHandler | 66 - com.hazelcast - 3.3.4 | [192.168.0.125]:5702 [cellar] [3.3.4] hz._hzInstance_1_cellar.IO.thread-in-1 Closing socket to endpoint Address[192.168.0.125]:5703, Cause:java.io.EOFException: Remote socket closed!
2015-01-27 18:39:10,592 | ERROR | FelixStartLevel | BlueprintContainerImpl | 15 - org.apache.aries.blueprint.core - 1.4.1 | Unable to start blueprint container for bundle org.apache.karaf.cellar.hazelcast
org.osgi.service.blueprint.container.ComponentDefinitionException: org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean groupManager
at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:299)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:239)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.getClasses(ServiceRecipe.java:372)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:185)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:703)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[9:org.apache.aries.util:1.1.0]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[9:org.apache.aries.util:1.1.0]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[9:org.apache.aries.util:1.1.0]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[9:org.apache.aries.util:1.1.0]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[9:org.apache.aries.util:1.1.0]
at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2092)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.2.1.jar:]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean groupManager
at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:933)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:907)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:888)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_17]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_17]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:284)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:251)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.getService(ServiceRecipe.java:354)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:507)
at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
at org.apache.felix.framework.Felix.getService(Felix.java:3568)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.getServiceSecurely(AbstractServiceReferenceRecipe.java:238)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.call(ReferenceListRecipe.java:211)
at Proxy7b861b7c_07b4_4f14_9b29_85f68cd989a5.getType(Unknown Source)
at org.apache.karaf.cellar.core.event.EventHandlerServiceRegistry.bind(EventHandlerServiceRegistry.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.invokeMethods(AbstractServiceReferenceRecipe.java:574)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$Listener.bind(AbstractServiceReferenceRecipe.java:556)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.bind(AbstractServiceReferenceRecipe.java:451)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ReferenceListRecipe.track(ReferenceListRecipe.java:134)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:368)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:347)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.Felix.registerService(Felix.java:3423)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)[org.apache.felix.framework-4.2.1.jar:]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:192)[15:org.apache.aries.blueprint.core:1.4.1]
... 19 more
Caused by: java.lang.ClassCastException: Proxydd524705_c712_4fa1_8eca_0b3c619efca8 cannot be cast to org.apache.karaf.cellar.core.Synchronizer
at org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:403)
at org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.registerGroup(HazelcastGroupManager.java:427)
at org.apache.karaf.cellar.hazelcast.HazelcastGroupManager.init(HazelcastGroupManager.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_17]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[15:org.apache.aries.blueprint.core:1.4.1]
at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[15:org.apache.aries.blueprint.core:1.4.1]
... 70 more
It happened the first time after I wanted to start the factory on node two and stays that way even after restart.
Cheers,
Ronny
Am 23.01.2015 um 08:07 schrieb Jean-Baptiste Onofré <jb...@nanthrax.net>:
Hi Ronny,
As you use cfg file in etc folder, having:
- config.listener=true
- and service.factoryPid in the excluded properties
should work. I mean the -1.cfg should be sync on both node.
Correct ?
Regards
JB
On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
> Hi Achim, Hi Jean-Baptiste,
>
> that was a lot of input for me.
> Let me start with your questions:
>
> >The ManagedServiceFactory comes from a bundle right ?
> >It's a bundle containing a service implementing ManagedServiceFactory.
>
> Right!
>
> >So, you have to sync the bundle with Cellar: you will have the factory
> on the nodes, and the sync on the config created by the factory.
> >You see what I mean ?
>
> I am not sure what you mean. Synchronising the bundle will lead to a
> factory on each node, right. But what do you mean with "the sync on the
> config created by the factory"? Do you mean the actual file or the object?
>
> >By the way, do you use etc/*.cfg file or config:* commands to create
> the config files ?
>
> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>
> >Sometime I think a management server isn't always the worst idea when
> configuring a cluster.
>
> No objections ;)
>
> Cheers,
> Ronny
>
> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Anyway, honestly, I don't see a huge issue just by excluding
> factoryPid and sync the PID. It's not perfect, but it works fine if
> the file are present in the etc folder.
>
> Regards
> JB
>
> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>
> JB, no problem at all.
> My first idea to use a UUID made of the nodeID and the
> factoryPid, does
> have some dangers though.
> If someone adds this configuration on two nodes it is
> duplicated. But
> one has to die one death ;)
>
> Sometime I think a management server isn't always the worst idea
> when
> configuring a cluster.
>
> regards, Achim
>
>
>
> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
> In order to manage service factory in a better way, I
> can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes
> from.
>
> It's the way that fileinstall manage each *.cfg file
> (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
> (built from
> commit
> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
> think I found a
> bug.
> I have two Karaf instances running. On both I installed
> Cellar and this
> simple project
> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
> After setting config.listener = true on both and
> removing
> service.factoryPid from the
> config.excluded.properties I
> dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf
> instance
> getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the
> problem. I
> suggest the Karaf updates itself and therefore
> calls the
> update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
> & Project Lead
> blog <http://notizblog.nierbeck.de/__>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ronny,
As you use cfg file in etc folder, having:
- config.listener=true
- and service.factoryPid in the excluded properties
should work. I mean the -1.cfg should be sync on both node.
Correct ?
Regards
JB
On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
> Hi Achim, Hi Jean-Baptiste,
>
> that was a lot of input for me.
> Let me start with your questions:
>
> >The ManagedServiceFactory comes from a bundle right ?
> >It's a bundle containing a service implementing ManagedServiceFactory.
>
> Right!
>
> >So, you have to sync the bundle with Cellar: you will have the factory
> on the nodes, and the sync on the config created by the factory.
> >You see what I mean ?
>
> I am not sure what you mean. Synchronising the bundle will lead to a
> factory on each node, right. But what do you mean with "the sync on the
> config created by the factory"? Do you mean the actual file or the object?
>
> >By the way, do you use etc/*.cfg file or config:* commands to create
> the config files ?
>
> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>
> >Sometime I think a management server isn't always the worst idea when
> configuring a cluster.
>
> No objections ;)
>
> Cheers,
> Ronny
>
> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Anyway, honestly, I don't see a huge issue just by excluding
> factoryPid and sync the PID. It's not perfect, but it works fine if
> the file are present in the etc folder.
>
> Regards
> JB
>
> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>
> JB, no problem at all.
> My first idea to use a UUID made of the nodeID and the
> factoryPid, does
> have some dangers though.
> If someone adds this configuration on two nodes it is
> duplicated. But
> one has to die one death ;)
>
> Sometime I think a management server isn't always the worst idea
> when
> configuring a cluster.
>
> regards, Achim
>
>
>
> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
> In order to manage service factory in a better way, I
> can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes
> from.
>
> It's the way that fileinstall manage each *.cfg file
> (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
> (built from
> commit
> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
> think I found a
> bug.
> I have two Karaf instances running. On both I installed
> Cellar and this
> simple project
> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
> After setting config.listener = true on both and
> removing
> service.factoryPid from the
> config.excluded.properties I
> dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf
> instance
> getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the
> problem. I
> suggest the Karaf updates itself and therefore
> calls the
> update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
> & Project Lead
> blog <http://notizblog.nierbeck.de/__>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Ronny Bräunlich <r....@gmail.com>.
Hi Jean-Baptiste,
the combination with shared configuration and excluded factoryPid sounds
like my initial problem, beacuse of which you made the properties blacklist
configurable (
http://karaf.922171.n3.nabble.com/Sharing-configuration-with-Cellar-td4037365.html#a4037374
).
But I can try this combination again on monday.
Improving the factory sync sounds good ;)
One question out of curiosity, why do you generate this factoryPid anyways?
Cheers,
Ronny
2015-01-23 8:52 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> By the way, Ronny, for Cellar 3.0.2/2.3.5, I will improve the factory sync
> with a special behaviour way service.factoryPid property is there.
>
> I will create a Jira about that.
>
> Regards
> JB
>
> On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
>
>> Hi Achim, Hi Jean-Baptiste,
>>
>> that was a lot of input for me.
>> Let me start with your questions:
>>
>> >The ManagedServiceFactory comes from a bundle right ?
>> >It's a bundle containing a service implementing ManagedServiceFactory.
>>
>> Right!
>>
>> >So, you have to sync the bundle with Cellar: you will have the factory
>> on the nodes, and the sync on the config created by the factory.
>> >You see what I mean ?
>>
>> I am not sure what you mean. Synchronising the bundle will lead to a
>> factory on each node, right. But what do you mean with "the sync on the
>> config created by the factory"? Do you mean the actual file or the object?
>>
>> >By the way, do you use etc/*.cfg file or config:* commands to create
>> the config files ?
>>
>> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>>
>> >Sometime I think a management server isn't always the worst idea when
>> configuring a cluster.
>>
>> No objections ;)
>>
>> Cheers,
>> Ronny
>>
>> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> Anyway, honestly, I don't see a huge issue just by excluding
>> factoryPid and sync the PID. It's not perfect, but it works fine if
>> the file are present in the etc folder.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>>
>> JB, no problem at all.
>> My first idea to use a UUID made of the nodeID and the
>> factoryPid, does
>> have some dangers though.
>> If someone adds this configuration on two nodes it is
>> duplicated. But
>> one has to die one death ;)
>>
>> Sometime I think a management server isn't always the worst idea
>> when
>> configuring a cluster.
>>
>> regards, Achim
>>
>>
>>
>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>> By the way, thanks Achim again for the discussion ;)
>>
>>
>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>
>> In order to manage service factory in a better way, I
>> can implement
>> something similar to fileinstall: a specific property
>> like
>> karaf.cellar.factoryPid to know where the factory comes
>> from.
>>
>> It's the way that fileinstall manage each *.cfg file
>> (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar
>> 3.0.1-SNAPSHOT
>> (built from
>> commit
>> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
>> think I found a
>> bug.
>> I have two Karaf instances running. On both I
>> installed
>> Cellar and this
>> simple project
>> https://github.com/____rbraeunlich/karaf-managed-____
>> service-factory-example
>> <https://github.com/__rbraeunlich/karaf-managed-__
>> service-factory-example>
>>
>>
>> <https://github.com/__rbraeunlich/karaf-managed-__
>> service-factory-example
>> <https://github.com/rbraeunlich/karaf-managed-
>> service-factory-example>>
>> After setting config.listener = true on both and
>> removing
>> service.factoryPid from the
>> config.excluded.properties I
>> dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf
>> instance
>> getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of
>> the
>> problem. I
>> suggest the Karaf updates itself and therefore
>> calls the
>> update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/__>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, Ronny, for Cellar 3.0.2/2.3.5, I will improve the factory
sync with a special behaviour way service.factoryPid property is there.
I will create a Jira about that.
Regards
JB
On 01/23/2015 07:38 AM, Ronny Bräunlich wrote:
> Hi Achim, Hi Jean-Baptiste,
>
> that was a lot of input for me.
> Let me start with your questions:
>
> >The ManagedServiceFactory comes from a bundle right ?
> >It's a bundle containing a service implementing ManagedServiceFactory.
>
> Right!
>
> >So, you have to sync the bundle with Cellar: you will have the factory
> on the nodes, and the sync on the config created by the factory.
> >You see what I mean ?
>
> I am not sure what you mean. Synchronising the bundle will lead to a
> factory on each node, right. But what do you mean with "the sync on the
> config created by the factory"? Do you mean the actual file or the object?
>
> >By the way, do you use etc/*.cfg file or config:* commands to create
> the config files ?
>
> I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>
> >Sometime I think a management server isn't always the worst idea when
> configuring a cluster.
>
> No objections ;)
>
> Cheers,
> Ronny
>
> 2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Anyway, honestly, I don't see a huge issue just by excluding
> factoryPid and sync the PID. It's not perfect, but it works fine if
> the file are present in the etc folder.
>
> Regards
> JB
>
> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>
> JB, no problem at all.
> My first idea to use a UUID made of the nodeID and the
> factoryPid, does
> have some dangers though.
> If someone adds this configuration on two nodes it is
> duplicated. But
> one has to die one death ;)
>
> Sometime I think a management server isn't always the worst idea
> when
> configuring a cluster.
>
> regards, Achim
>
>
>
> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
> In order to manage service factory in a better way, I
> can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes
> from.
>
> It's the way that fileinstall manage each *.cfg file
> (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
> (built from
> commit
> 7a598b285f7b302efa15d9887dfea9____d855b9951a) and I
> think I found a
> bug.
> I have two Karaf instances running. On both I installed
> Cellar and this
> simple project
> https://github.com/____rbraeunlich/karaf-managed-____service-factory-example
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example>
>
> <https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>>
> After setting config.listener = true on both and
> removing
> service.factoryPid from the
> config.excluded.properties I
> dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf
> instance
> getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the
> problem. I
> suggest the Karaf updates itself and therefore
> calls the
> update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> Committer
> & Project Lead
> blog <http://notizblog.nierbeck.de/__>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Ronny Bräunlich <r....@gmail.com>.
Hi Achim, Hi Jean-Baptiste,
that was a lot of input for me.
Let me start with your questions:
>The ManagedServiceFactory comes from a bundle right ?
>It's a bundle containing a service implementing ManagedServiceFactory.
Right!
>So, you have to sync the bundle with Cellar: you will have the factory on
the nodes, and the sync on the config created by the factory.
>You see what I mean ?
I am not sure what you mean. Synchronising the bundle will lead to a
factory on each node, right. But what do you mean with "the sync on the
config created by the factory"? Do you mean the actual file or the object?
>By the way, do you use etc/*.cfg file or config:* commands to create the
config files ?
I used a .cfg file. As you taught me its name is the Factory PID "-1.cfg".
>Sometime I think a management server isn't always the worst idea when
configuring a cluster.
No objections ;)
Cheers,
Ronny
2015-01-22 21:24 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Anyway, honestly, I don't see a huge issue just by excluding factoryPid
> and sync the PID. It's not perfect, but it works fine if the file are
> present in the etc folder.
>
> Regards
> JB
>
> On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
>
>> JB, no problem at all.
>> My first idea to use a UUID made of the nodeID and the factoryPid, does
>> have some dangers though.
>> If someone adds this configuration on two nodes it is duplicated. But
>> one has to die one death ;)
>>
>> Sometime I think a management server isn't always the worst idea when
>> configuring a cluster.
>>
>> regards, Achim
>>
>>
>>
>> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> By the way, thanks Achim again for the discussion ;)
>>
>>
>> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>>
>> In order to manage service factory in a better way, I can
>> implement
>> something similar to fileinstall: a specific property like
>> karaf.cellar.factoryPid to know where the factory comes from.
>>
>> It's the way that fileinstall manage each *.cfg file (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
>> (built from
>> commit 7a598b285f7b302efa15d9887dfea9__d855b9951a) and I
>> think I found a
>> bug.
>> I have two Karaf instances running. On both I installed
>> Cellar and this
>> simple project
>> https://github.com/__rbraeunlich/karaf-managed-__
>> service-factory-example
>> <https://github.com/rbraeunlich/karaf-managed-
>> service-factory-example>
>> After setting config.listener = true on both and removing
>> service.factoryPid from the config.excluded.properties I
>> dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf instance
>> getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the
>> problem. I
>> suggest the Karaf updates itself and therefore calls the
>> update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Anyway, honestly, I don't see a huge issue just by excluding factoryPid
and sync the PID. It's not perfect, but it works fine if the file are
present in the etc folder.
Regards
JB
On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
> JB, no problem at all.
> My first idea to use a UUID made of the nodeID and the factoryPid, does
> have some dangers though.
> If someone adds this configuration on two nodes it is duplicated. But
> one has to die one death ;)
>
> Sometime I think a management server isn't always the worst idea when
> configuring a cluster.
>
> regards, Achim
>
>
>
> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
> In order to manage service factory in a better way, I can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes from.
>
> It's the way that fileinstall manage each *.cfg file (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
> (built from
> commit 7a598b285f7b302efa15d9887dfea9__d855b9951a) and I
> think I found a
> bug.
> I have two Karaf instances running. On both I installed
> Cellar and this
> simple project
> https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I
> dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance
> getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the
> problem. I
> suggest the Karaf updates itself and therefore calls the
> update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
> & Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree. It's a topology that I plan on Cellar: define a node as a
master/management node.
Regards
JB
On 01/22/2015 08:50 PM, Achim Nierbeck wrote:
> JB, no problem at all.
> My first idea to use a UUID made of the nodeID and the factoryPid, does
> have some dangers though.
> If someone adds this configuration on two nodes it is duplicated. But
> one has to die one death ;)
>
> Sometime I think a management server isn't always the worst idea when
> configuring a cluster.
>
> regards, Achim
>
>
>
> 2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
> In order to manage service factory in a better way, I can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes from.
>
> It's the way that fileinstall manage each *.cfg file (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT
> (built from
> commit 7a598b285f7b302efa15d9887dfea9__d855b9951a) and I
> think I found a
> bug.
> I have two Karaf instances running. On both I installed
> Cellar and this
> simple project
> https://github.com/__rbraeunlich/karaf-managed-__service-factory-example
> <https://github.com/rbraeunlich/karaf-managed-service-factory-example>
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I
> dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance
> getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the
> problem. I
> suggest the Karaf updates itself and therefore calls the
> update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
> & Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Achim Nierbeck <bc...@googlemail.com>.
JB, no problem at all.
My first idea to use a UUID made of the nodeID and the factoryPid, does
have some dangers though.
If someone adds this configuration on two nodes it is duplicated. But one
has to die one death ;)
Sometime I think a management server isn't always the worst idea when
configuring a cluster.
regards, Achim
2015-01-22 20:43 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> By the way, thanks Achim again for the discussion ;)
>
>
> On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
>
>> In order to manage service factory in a better way, I can implement
>> something similar to fileinstall: a specific property like
>> karaf.cellar.factoryPid to know where the factory comes from.
>>
>> It's the way that fileinstall manage each *.cfg file (adding the
>> felix.fileinstall.filename property).
>>
>> Let me dig around that and improve this.
>>
>> Regards
>> JB
>>
>> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>>
>>> Hi everyone,
>>>
>>> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
>>> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a
>>> bug.
>>> I have two Karaf instances running. On both I installed Cellar and this
>>> simple project
>>> https://github.com/rbraeunlich/karaf-managed-service-factory-example
>>> After setting config.listener = true on both and removing
>>> service.factoryPid from the config.excluded.properties I dropped a
>>> config file into the etc/ directory.
>>> Then I could see the factory on the first Karaf instance getting called
>>> with the properties roughly every 100ms.
>>> Debugging the Karaf couldn’t show me the source of the problem. I
>>> suggest the Karaf updates itself and therefore calls the update() method
>>> all the time.
>>> The second instance didn’t make a move all the time.
>>>
>>> Does anyone have a clue?
>>>
>>> Cheers,
>>> Ronny
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, thanks Achim again for the discussion ;)
On 01/22/2015 08:41 PM, Jean-Baptiste Onofré wrote:
> In order to manage service factory in a better way, I can implement
> something similar to fileinstall: a specific property like
> karaf.cellar.factoryPid to know where the factory comes from.
>
> It's the way that fileinstall manage each *.cfg file (adding the
> felix.fileinstall.filename property).
>
> Let me dig around that and improve this.
>
> Regards
> JB
>
> On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
>> Hi everyone,
>>
>> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
>> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a
>> bug.
>> I have two Karaf instances running. On both I installed Cellar and this
>> simple project
>> https://github.com/rbraeunlich/karaf-managed-service-factory-example
>> After setting config.listener = true on both and removing
>> service.factoryPid from the config.excluded.properties I dropped a
>> config file into the etc/ directory.
>> Then I could see the factory on the first Karaf instance getting called
>> with the properties roughly every 100ms.
>> Debugging the Karaf couldn’t show me the source of the problem. I
>> suggest the Karaf updates itself and therefore calls the update() method
>> all the time.
>> The second instance didn’t make a move all the time.
>>
>> Does anyone have a clue?
>>
>> Cheers,
>> Ronny
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
In order to manage service factory in a better way, I can implement
something similar to fileinstall: a specific property like
karaf.cellar.factoryPid to know where the factory comes from.
It's the way that fileinstall manage each *.cfg file (adding the
felix.fileinstall.filename property).
Let me dig around that and improve this.
Regards
JB
On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
> I have two Karaf instances running. On both I installed Cellar and this
> simple project
> https://github.com/rbraeunlich/karaf-managed-service-factory-example
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the problem. I
> suggest the Karaf updates itself and therefore calls the update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problem with Cellar and ManagedServiceFactories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ronny,
it's one of the reason why factoryPid is an excluded property.
The reason is that a different pid is created each time, so Cellar sync
it. When another node receives it, it creates a new one (different from
the other as it's factory), so it sync it, etc, etc.
As I already said to you, factoryPid is "local" to a node and should not
be sync. That's why you should leave the factoryPid property in the
excluded properties.
Regards
JB
On 01/22/2015 06:27 PM, Ronny Bräunlich wrote:
> Hi everyone,
>
> I am using Apache Karaf 3.0.2 and Cellar 3.0.1-SNAPSHOT (built from
> commit 7a598b285f7b302efa15d9887dfea9d855b9951a) and I think I found a bug.
> I have two Karaf instances running. On both I installed Cellar and this
> simple project
> https://github.com/rbraeunlich/karaf-managed-service-factory-example
> After setting config.listener = true on both and removing
> service.factoryPid from the config.excluded.properties I dropped a
> config file into the etc/ directory.
> Then I could see the factory on the first Karaf instance getting called
> with the properties roughly every 100ms.
> Debugging the Karaf couldn’t show me the source of the problem. I
> suggest the Karaf updates itself and therefore calls the update() method
> all the time.
> The second instance didn’t make a move all the time.
>
> Does anyone have a clue?
>
> Cheers,
> Ronny
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com