geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: gcache imlementation ideas[long]
Date Mon, 18 Sep 2006 19:50:34 GMT
On 9/15/06, Jeff Genender <jgenender@apache.org> 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/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/discovery/
>
> Failover through the failover protocol ;-) We will use it too:
>

Failover is protocol specific, since you are not using the ActiveMQ
protocol, just the same transport  pattern, you will may to
re-implement parts of the failover protocol.  The bits where on
failover client state is re-established with the server.  So most of
the works would be in the StateTracker object that the failover
protocol uses.

> http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/failover/
>
> Master/slave we are writing...but will reuse some of the infrastructure.
>

For activemq M/S is a bit simplistic where the client uses the
failover protocol and the master broker handles replicating state to
the slave.

Regards,
Hiram

> Jeff
>
> >
> > --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 start with TCP communication.
> >>>
> >>> Why do you think that AMQ will not perform well?
> >>>
> >>
> >> AMQ will perform well...its a great JMS implementation.  But for the
> >> initial shot I want to go for pure speed.  AMQ uses openwire as its
> >> transport engine, but it has a JMS impl behind it.  I just want
> >> openwire, with just a cache behind it...take out the middle-man, JMS.
> >> But with that said, we *will* make a JMS strategy and use AMQ...but as a
> >> client.
> >>
> >>>
> >>>> I definitely want to
> >>>> have a JMS strategy...maybe next.  But initially I don't want any
> >>>> dependencies on other servers or brokers.
> >>>>
> >>>> With that said, after looking at openwire, the comm marshaller for
> >>>> ActiveMQ, there is a lot to leverage there and will prevent a
> >>>> rewrite of
> >>>> the comm layer.  So, there will be some use of that code base
> >>>> initially.
> >>>
> >>> IMO, AMQ already provides a rich clustering environment, with failover,
> >>> master-slave, dynamic discovery, firewall-happy transports, monitoring
> >>> and a heck of a lot more.
> >>>
> >>
> >> But at the end of the day, its a JMS engine.  Can we write clustering
> >> based nearly entirely on JMS?  Yes.  But then for those who do not want
> >> to use JMS, we are still stuck with the overhead of the protocol and any
> >> baggage that comes along with it.  Lets use AMQ as a client to the
> >> clustering (a pluggable strategy).
> >>
> >>
> >>> Seems like it would be a waste to go and re-implement all of that.  It
> >>> also seems that if you wanted to get something up sooner, that it would
> >>> be much easier to design a AMQ strategy first, which means that you only
> >>> have to worry about the message passing to sync up and invalidate state,
> >>> rather than all of the details of who is in what cluster, failing over,
> >>> blah, blah...
> >>>
> >>
> >> Not reimplementing.  See below...
> >>
> >>> And, I guess that if after that was implemented you still thought it was
> >>> not fast enough, then it might be better to get AMQ fixed to perform
> >>> better, though I don't think that the performance using AMQ will differ
> >>> all that much from a custom socket protocol to pass messages.
> >>>
> >>
> >> Sure it would.  We are interested only in pushing objects and light
> >> messages (eviction, etc). Adding our messages on top of the JMS commands
> >> minimally doubles the amount of data (from a messaging perspective) that
> >> needs to go over the wire.
> >>
> >>> I am a huge fan of AMQ and would really like to see G exploit its
> >>> network communications facilities as much as possible.
> >>>
> >>
> >> I am a big fan of it too...and we are exploiting it...look at the commit
> >> log...its a practical C/P of the openwire code from AMQ ;-)  In
> >> discussing this with Hiram, we agreed that the openwire protocol would
> >> be good for many projects, not just AMQ.  So we are killing 2 birds with
> >> one stone.  We are pulling out openwire and trying to make it more
> >> generic, so that it could live as its own jar so that many other
> >> projects can use it.
> >>
> >>> IMO, this is the best way to get the most features for clustering up and
> >>> running sooner, with less code to maintain.
> >>>
> >>
> >> I think that is what we are trying to do here to a large extent.
> >>
> >> Great discussion!  More! more!
> >>
> >>> --jason
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message