Bridge between zookeeper and OSGI configuration admin

ZooKeeper ConfigurationAdmin bridge

Hi Sergey,

Some comments below...

On 13 May 2010 12:42, Sergey Beryozkin <sbery### @gmail.com> wrote:
> So now that we have a passing RI I think it would make sense to
start
> planning a CXF-DOSGi release. I'm wondering what we should do
before
> that...
> 1. There are some SEVERE 'warnings' coming up, I believe from the
> Topology Manager. We should probably take a look at those.
> 2. I once added some Discovery system tests, which I ended up not
> enabling because of memory issues. I might want to try and get
them
> working on all platforms.
> 3. Anything else?
>
>
 - consolidation of DOSGI RI specific properties. Example, you added a
useful
 property called "org.apache.cxf.ws.port" so JAXRS endpoints need to
'catch
 up' with "org.apache.cxf.rs.port".
 Perhaps we can continue adding such 'parallel' properties, but I'm
 wondering, can "org.apache.cxf.ws.port"
 be replaced with "org.apache.cxf.endpoint.port" or
 "org.apache.cxf.http.port" ? Later on, in post 1.2, we can deprecates
some
 of other 'duplicate' properties.

Well, the Remote Services Admin spec mandates that the configuration
properties follow a certain pattern. If the configuration type is
called org.apache.cxf.ws then its specific configuration variables
should be called org.apache.cxf.ws.something (see table 122.1 in the
OSGi 4.2 Enterprise Spec http://www.osgi.org/Download/Release4V42).
This is to avoid name clashes when you want to expose a service using
multiple Remote Service implementations that may not be aware of each
other. So to be compliant we have to live with parallel properties.

I do agree on matching up the properties where this makes sense across
org.apache.cxf.ws and org.apache.cxf.rs

 - HTTPS support ? May be a discussion on the dev list can be
initiated, a
 solution agreed upon and then someone from the community can step
forward
 and work on it ? As a side note, a CXF user has approached me
regarding
 fixing a JAXRS Jettison issue in DOSGI 1.1 (default Jettison provider
does
 not work in DOSGi 1.1, needs to be fixed for 1.2 too) so I think
there are
 experienced and motivated users who can help...

While I agree that this would be great to have, I'm not sure if we
should wait for it to be finished. I'm not aware of anyone working on
this at the moment (please correct me if I'm wrong!). Months of work
have gone in making CXF-DOSGi compliant with the spec and I don't
think we should hold releasing this off until a nice piece of
functionality which hasn't even been started on has been finished.
There's nothing wrong with releasing often, so if this functionality
appears we can do a release again, unless someone is already working
on HTTPS support of course...

Best regards,

David

Hi,

I just committed some changes which remove the "severe" messages that
where produced during the normal operation of the Topology Manager. Two
of them where obsolete by now and one concerned some missing
functionality of the Topology Manager that I've now added. This
concerned in particular the behaviour of the Topology Manager regarding
the import of services when the DSW is detected/added after the service
to be imported was found which is supported now.

Cheers,
Marc

On 05/12/2010 06:40 PM, David Bosschaert wrote:
 Hi all,

 Earlier this week the OSGi Alliance has approved the OSGi 4.2
 Enterprise Conformance Tests and Reference Implementations. The
 CXF-DOSGi project [1] is the Reference Implementation for the
 following OSGi 4.2 specs [2]:

 * Chapter 13 - Remote Services
 This spec describes Distributed OSGi from a user's point of view. It
 standardizes the properties that can be put on an OSGi service to
make
 it available remotely and how a consumer can find out whether it's
 dealing with a local service or a remote one.

 * Chapter 122 - Remote Services Admin
 This spec standardizes the interfaces between internal components
 Remote Services implementations typically have. A Distribution
 Provider, Topology Manager and Discovery System. This makes it
 possible to mix&match these components from various
implementations.
 For more information see slides 6-8 at [3].

 Many kudos to Marc Schaaf as he did a lot of the recent RI work.
 Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
 tests despite his busy schedule.

 So now that we have a passing RI I think it would make sense to start
 planning a CXF-DOSGi release. I'm wondering what we should do before
 that...
 1. There are some SEVERE 'warnings' coming up, I believe from the
 Topology Manager. We should probably take a look at those.
 2. I once added some Discovery system tests, which I ended up not
 enabling because of memory issues. I might want to try and get them
 working on all platforms.
 3. Anything else?

 Best regards,

 David

 [1] http://cxf.apache.org/distributed-osgi.html
 [2] http://www.osgi.org/Download/Release4V42
 [3] http://www.slideshare.net/bosschaert/...os-gi42enterprise
   

any idea when 5.4.0 will be available?

greez,

dialsc

Geoffrey Arnold wrote:
 
 Hi all,
 
 We have a forwarding bridge between an embedded broker in one VM and
a
 remote broker in another VM using the examples from the
network-of-brokers
 documentation[1].  While testing failover, we left the embedded
broker VM
 running overnight but did not start the remote broker VM.  NOTE: The
 embedded broker VM was idle (we were not testing application logic).
 
 In the morning the embedded broker VM threw an OutOfMemoryError:
 
 	Exception in thread "Simple Discovery Agent:
 java.util.concurrent.ThreadPoolExecutor$Work### @61472b3c"
 java.lang.OutOfMemoryError: Java heap space
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:60)
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:69)
 		at

org.apache.activemq.openwire.OpenWireFormatFactory.createWireFormat(OpenWireFormatFactory.java:62)
 		at

org.apache.activemq.transport.TransportFactory.createWireFormat(TransportFactory.java:212)
 		at

org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:140)
 		at

org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:67)
 		at

org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:111)
 		at

org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent$1.run(SimpleDiscoveryAgent.java:164)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 		at java.lang.Thread.run(Thread.java:637)
 
 Our logs contained repeated (and expected) messages indicating that a
 connection could not be established with the remote broker.  The one
thing
 that stands out from these logs is that a new thread was created in
the
 embedded broker VM on each attempt to connect to the remote broker
VM:
 
 	[1259881226751][Thread-10] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881227757][Thread-11] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881229762][Thread-12] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	...
 	[1259888976178][Thread-267] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889006398][Thread-268] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889036611][Thread-269] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 
 The embedded broker VM is configured via Spring as follows:
 
 	<amq:broker id="embeddedBroker" brokerName="embeddedBroker"
useJmx="true"
 persistent="false" useShutdownHook="true">
 		<amq:managementContext>
 			<amq:managementContext createConnector="false"/>
 		</amq:managementContext>
 		<amq:networkConnectors>
 			<amq:networkConnector uri="static:(tcp://localhost:61616)"/>
 		</amq:networkConnectors>
 	</amq:broker>
 
 Any help would be greatly appreciated.
 
 Thanks,
 Geoff.
 
 [1] http://activemq.apache.org/networks-of-brokers.html
 

cool, thx for the info!

greez,

dialsc

Geoffrey Arnold wrote:
 
 Hi all,
 
 We have a forwarding bridge between an embedded broker in one VM and
a
 remote broker in another VM using the examples from the
network-of-brokers
 documentation[1].  While testing failover, we left the embedded
broker VM
 running overnight but did not start the remote broker VM.  NOTE: The
 embedded broker VM was idle (we were not testing application logic).
 
 In the morning the embedded broker VM threw an OutOfMemoryError:
 
 	Exception in thread "Simple Discovery Agent:
 java.util.concurrent.ThreadPoolExecutor$Wor### @61472b3c"
 java.lang.OutOfMemoryError: Java heap space
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:60)
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:69)
 		at

org.apache.activemq.openwire.OpenWireFormatFactory.createWireFormat(OpenWireFormatFactory.java:62)
 		at

org.apache.activemq.transport.TransportFactory.createWireFormat(TransportFactory.java:212)
 		at

org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:140)
 		at

org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:67)
 		at

org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:111)
 		at

org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent$1.run(SimpleDiscoveryAgent.java:164)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 		at java.lang.Thread.run(Thread.java:637)
 
 Our logs contained repeated (and expected) messages indicating that a
 connection could not be established with the remote broker.  The one
thing
 that stands out from these logs is that a new thread was created in
the
 embedded broker VM on each attempt to connect to the remote broker
VM:
 
 	[1259881226751][Thread-10] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881227757][Thread-11] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881229762][Thread-12] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	...
 	[1259888976178][Thread-267] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889006398][Thread-268] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889036611][Thread-269] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 
 The embedded broker VM is configured via Spring as follows:
 
 	<amq:broker id="embeddedBroker" brokerName="embeddedBroker"
useJmx="true"
 persistent="false" useShutdownHook="true">
 		<amq:managementContext>
 			<amq:managementContext createConnector="false"/>
 		</amq:managementContext>
 		<amq:networkConnectors>
 			<amq:networkConnector uri="static:(tcp://localhost:61616)"/>
 		</amq:networkConnectors>
 	</amq:broker>
 
 Any help would be greatly appreciated.
 
 Thanks,
 Geoff.
 
 [1] http://activemq.apache.org/networks-of-brokers.html
 

hello,

we are running version 5.3.1 but facing the same problem.



Geoffrey Arnold wrote:
 
 Hi all,
 
 We have a forwarding bridge between an embedded broker in one VM and
a
 remote broker in another VM using the examples from the
network-of-brokers
 documentation[1].  While testing failover, we left the embedded
broker VM
 running overnight but did not start the remote broker VM.  NOTE: The
 embedded broker VM was idle (we were not testing application logic).
 
 In the morning the embedded broker VM threw an OutOfMemoryError:
 
 	Exception in thread "Simple Discovery Agent:
 java.util.concurrent.ThreadPoolExecutor$Work### @61472b3c"
 java.lang.OutOfMemoryError: Java heap space
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:60)
 		at

org.apache.activemq.openwire.OpenWireFormat.<init>(OpenWireFormat.java:69)
 		at

org.apache.activemq.openwire.OpenWireFormatFactory.createWireFormat(OpenWireFormatFactory.java:62)
 		at

org.apache.activemq.transport.TransportFactory.createWireFormat(TransportFactory.java:212)
 		at

org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:140)
 		at

org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:67)
 		at

org.apache.activemq.network.DiscoveryNetworkConnector.onServiceAdd(DiscoveryNetworkConnector.java:111)
 		at

org.apache.activemq.transport.discovery.simple.SimpleDiscoveryAgent$1.run(SimpleDiscoveryAgent.java:164)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 		at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 		at java.lang.Thread.run(Thread.java:637)
 
 Our logs contained repeated (and expected) messages indicating that a
 connection could not be established with the remote broker.  The one
thing
 that stands out from these logs is that a new thread was created in
the
 embedded broker VM on each attempt to connect to the remote broker
VM:
 
 	[1259881226751][Thread-10] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881227757][Thread-11] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259881229762][Thread-12] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	...
 	[1259888976178][Thread-267] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889006398][Thread-268] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 	[1259889036611][Thread-269] Could not start network bridge between:
 vm://embeddedBroker and: tcp://localhost:61616 due to:
 java.net.ConnectException: Connection refused
 
 The embedded broker VM is configured via Spring as follows:
 
 	<amq:broker id="embeddedBroker" brokerName="embeddedBroker"
useJmx="true"
 persistent="false" useShutdownHook="true">
 		<amq:managementContext>
 			<amq:managementContext createConnector="false"/>
 		</amq:managementContext>
 		<amq:networkConnectors>
 			<amq:networkConnector uri="static:(tcp://localhost:61616)"/>
 		</amq:networkConnectors>
 	</amq:broker>
 
 Any help would be greatly appreciated.
 
 Thanks,
 Geoff.
 
 [1] http://activemq.apache.org/networks-of-brokers.html
 

Hi,

I am using "forwarding bridge" in many-to-one configuration. Many ActiveMQ
clients (just plain ActiveMQ local server acting as a buffer) will be
forwarding several queues defined with staticallyIncludedDestinations to
central (remote) ActiveMQ. So far, experiments confirm that all is working
fine.

However there is one problem with forwarding bridge - it keeps TCP/IP
connection all the time. As there could be really many ActiveMQ clients
=>
that will kill network router with overload of active TCP/IP connections. 

Most of these ActiveMQ clients will be idle 99% of the time (no data in
queues to forward).

Is there a way to configure client ActiveMQ in forwarding bridge mode to
connect to remote server ONLY when there is something to be sent (and
disconnect when done, eg queue empty) ?

Can that be done by configuration or the only option is coding an
application ?

PS. Google did not help me on this one.:-(

Tom

Use links to osgi jndi (that look up osgi services) rather than looking up
gbeans

Samples should lookup osgi services spec compliant using "osgi:service"
rather than "aries:services" unless specific aries:service capabilities are
needed

osgi:addcommand/osgi:removecommand should apply to current session vs
global to the osgi framework

Interceptor bridge to support non blocking routing engine

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Carl Steinbach updated HIVE-232:

Configuration.getInt() should define its accepted inputs, and should also
accept octal

VFSFileChangedReloadingStrategy.init() uses configuration before checking
it for null

update ZooKeeper java client to optionally use Netty for connections

    [
https://issues.apache.org/jira/browse...4#action_12889264
] 

Patrick Hunt commented on ZOOKEEPER-816:

    [
https://issues.apache.org/jira/browse...4#action_12889904
] 

Patrick Hunt commented on ZOOKEEPER-816:

    [
https://issues.apache.org/jira/browse...4#action_12889814
] 

Flavio Paiva Junqueira commented on ZOOKEEPER-816:

Detecting and diagnosing elusive bugs and faults in Zookeeper

    [
https://issues.apache.org/jira/browse...2#action_12889202
] 

Miguel Correia commented on ZOOKEEPER-816: