Hi,
I think such an API will start to be useful for people interested to
implement distributed or clustered services. At this stage, there is
not a real need for such a capability; so, this may be a little bit
premature to introduce it.
After some experiments with an API similar to the pr
I addressed the discussion about "what transport" do we use, a long time
ago by creating an agnostic API to plug into.
http://marc.theaimsgroup.com/?l=geronimo-dev&m=115281186718399&w=2
http://people.apache.org/~fhanik/geronimo-cluster-api.zip
this way, we can continue the "pluggability" of G,
On 9/15/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Jason Dillon wrote:
> Um, but does openwire handle discovery, failover, master/slave... ?
Discovery done through the mcast openwire transport ;-) We will reuse it:
Discovery is simple enough..
http://svn.apache.org/repos/asf/incubator/a
Okay, I will shut up now :-P
--jason
On Sep 15, 2006, at 11:40 AM, Jeff Genender wrote:
Jason Dillon wrote:
Um, but does openwire handle discovery, failover, master/slave... ?
Discovery done through the mcast openwire transport ;-) We will
reuse it:
http://svn.apache.org/repos/asf/in
Jason Dillon wrote:
> Um, but does openwire handle discovery, failover, master/slave... ?
Discovery done through the mcast openwire transport ;-) We will reuse it:
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/discovery/
Fail
Um, but does openwire handle discovery, failover, master/slave... ?
--jason
On Sep 15, 2006, at 4:07 AM, Jeff Genender wrote:
Jason Dillon wrote:
On Sep 14, 2006, at 7:56 AM, Jeff Genender wrote:
The JMS provider would be a pluggable comm strategy. For
performance
reasons, I want to st
I will wait and see what you come up with first :-)
--jason
On Sep 15, 2006, at 2:25 AM, Jeff Genender wrote:
Jason Dillon wrote:
Aight... well, lets see the interfaces and the socket impl and I will
write the jms impl and see which fairs better with the most
features :-P
Write it!
Jason Dillon wrote:
> On Sep 14, 2006, at 7:56 AM, Jeff Genender wrote:
>> The JMS provider would be a pluggable comm strategy. For performance
>> reasons, I want to start with TCP communication.
>
> Why do you think that AMQ will not perform well?
>
AMQ will perform well...its a great JMS im
Jason Dillon wrote:
> Aight... well, lets see the interfaces and the socket impl and I will
> write the jms impl and see which fairs better with the most features :-P
>
Write it! That would be awesome ;-)
As a side note, shall we race? TCP vs JMS? ;-) j/k
> --jason
>
>
> On Sep 14, 2006,
Hey Jeff,
Good to see this stuff gaining some traction!
If I could try to summarize to make sure I've got what you are
saying. The intent is to rework the communication back end that
ehcache is using to make it something more performant than the
existing RMI impl and use the existing ehcac
Aight... well, lets see the interfaces and the socket impl and I will
write the jms impl and see which fairs better with the most features :-P
--jason
On Sep 14, 2006, at 8:17 PM, Kevan Miller wrote:
I'm with Jeff on this one...
I've seen this done w/ JMS. However, there's so much JMS over
I'm with Jeff on this one...
I've seen this done w/ JMS. However, there's so much JMS overhead
that you don't need (message formats, persistent messages, delivery
semantics, etc).
I recall Jeff was talking to Hiram about ActiveIO -- that's the more
appropriate way to go. Reuse common tech
On Sep 14, 2006, at 7:56 AM, Jeff Genender wrote:
The JMS provider would be a pluggable comm strategy. For performance
reasons, I want to start with TCP communication.
Why do you think that AMQ will not perform well?
I definitely want to
have a JMS strategy...maybe next. But initially I do
Jacek Laskowski wrote:
> On 9/13/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>> The code lives in sandbox/gcache. Its in it's early stages.
>
> Could you describe what's already there? A wiki page would be of help,
> too. Do you plan to convert these fancy ascii arts into UML diagrams?
> I
Jason Dillon wrote:
> Why not use ActiveMQ for communication and take advantage of its broker
> network for failover?
>
The JMS provider would be a pluggable comm strategy. For performance
reasons, I want to start with TCP communication. I definitely want to
have a JMS strategy...maybe next.
Jacek Laskowski wrote:
> On 9/14/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
>> Why not use ActiveMQ for communication and take advantage of its
>> broker network for failover?
>
> I'd be better off leaving answering the question to Jeff, but here's
> my take on Jeff's proposal that may answer y
On 9/13/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
The code lives in sandbox/gcache. Its in it's early stages.
Could you describe what's already there? A wiki page would be of help,
too. Do you plan to convert these fancy ascii arts into UML diagrams?
I think a jira issue would bring some a
On 9/14/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Why not use ActiveMQ for communication and take advantage of its
broker network for failover?
I'd be better off leaving answering the question to Jeff, but here's
my take on Jeff's proposal that may answer your question.
AFAIUI, Jeff proposes
Why not use ActiveMQ for communication and take advantage of its
broker network for failover?
--jason
On Sep 12, 2006, at 9:19 AM, Jeff Genender wrote:
I wanted to go over a high level design on a gcache cache component
and
get some feedback, input and invite folks who are interested to
Matt Hogstrom wrote:
> Some questions to clarify my mind.
>
> How I think about this is we have a "clustering" component that allows
> for the configuration, communication and failover components of the
> clustering. This way a user can set up a cluster of servers that
> basically will be inter
Matt it is ehcache (http://ehcache.sourceforge.net/)
-dain
ACII art provided by a cool open source ASCII editor called JavE:
http://www.jave.de/
I am hoping to have something usable within a couple of weeks, although
the more help I get and discussion we have, the faster this bad boy will
get going ;-)
The code lives in sandbox/gcache. Its in it's earl
Some questions to clarify my mind.
How I think about this is we have a "clustering" component that
allows for the configuration, communication and failover components
of the clustering. This way a user can set up a cluster of servers
that basically will be interoperating. This is independ
That is some sweet ascii art. What did you use?
This seems like a good KISS design. How long until you think we can
start to use it?
-dain
On Sep 12, 2006, at 9:19 AM, Jeff Genender wrote:
I wanted to go over a high level design on a gcache cache component
and
get some feedback, input a
I wanted to go over a high level design on a gcache cache component and
get some feedback, input and invite folks who are interested to join in.
..so here it goes...
The gcache will be one of several cache/clustering offerings...but
starting off with the first one...
The first pass I want to go w
25 matches
Mail list logo
