Ioannis,
Before considering to resolve something through Apache Way, I think that
it is interesting that we take the time to discuss, to review what
Guillaume suggest and confront this with the idea introduced by
Jean-Baptiste, you and the others. Karaf 3.0 and our communities of
users deserve it and it makes no sense to create a schism within Karaf
project.
Regards,
Charles
On 15/04/11 09:01, Ioannis Canellos wrote:
I consider clustering to be a first class feature of karaf 3.x and I
would like to see it as part of the karaf trunk and not as part of 3rd
library which is partially open sourced. In any case since there are a
lot of different views, let's resolve this "the apache way" and vote
on which solution we want to add to the karaf trunk.
On Friday, April 15, 2011, Guillaume Nodet<gno...@gmail.com> wrote:
So I have another proposal to put on the table.
I've been working since a few weeks on this very subject as part of my
day job at FuseSource, and we've just open sourced some components:
http://fabric.fusesource.org/
A *very * rough overview is available at
http://fabric.fusesource.org/documentation/user-guide.html
and a getting started guide at
http://fabric.fusesource.org/documentation/getting-started.html
Feedback welcome.
On Thu, Apr 14, 2011 at 10:48, Jean-Baptiste Onofré<j...@nanthrax.net> wrote:
I'm totally agree with Chris.
Ioannis and I are aware that the solution is not the killer one, that we can
do a lot of things better.
However, the solution has the main advantage to exist and work.
People (Karaf contributors and community) can play with this cluster
implementation and enhance it.
So here's my +1 also.
Regards
JB
On 04/13/2011 05:32 PM, Chris Custine wrote:
+1 for bringing this code to Karaf.
I haven't tested this out thoroughly or even looked deeply at the
code, but in general I like this idea. I certainly agree with some of
Guillaume's points, however unless there is a suitable alternative I
think this will provide a good starting point for the community to get
involved and improve it.
Chris
--
Chris Custine
My Blog :: http://blog.organicelement.com
On Wed, Apr 13, 2011 at 09:06, Ioannis Canellos<ioca...@gmail.com> wrote:
Guillaume, I haven't seen all your points, so here are some comments for
the
rest:
*Automatic discovery is really a myth imho. Such protocols have to use
multicast and multicast is really forbidden in a lot of places. So
*relying* on multicast would be a mistake I think. I've seen
hazelcast can be configured using static ips which sounds better
(though multicast is nice for demos, no problem with that).*
In places like EC2 or other Cloud platforms, indeed multicast is
forbidden,
but in a private cluster, multicast is great.
So I would say that automatic discovery is not panacea, but its still a
very
strong feature.
*That's really my problem. Maybe it's a misunderstanding, but when you*
* say "replication", I hear same thing everywhere, which I have a
problem with.
I think that definitely solve some problems, but it looks too limited.*
Let's don't stick to the "term" replication. Let's just say that it
provides
means to configure a group of nodes instead of a single one. And note
that
not all nodes are in total synch. You can configure what you want to
sync.
The configuration means can be extended and become more granular in order
to
fit all needs.
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf<http://karaf.apache.org/> Committer& PMC
Apache ServiceMix<http://servicemix.apache.org/> Committer
*
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/
