geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: gcache imlementation ideas[long]
Date Fri, 15 Sep 2006 11:07:57 GMT

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

>> 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

View raw message