geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: gcache imlementation ideas[long]
Date Fri, 15 Sep 2006 18:46:57 GMT
Okay, I will shut up now :-P


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:
> core/src/main/java/org/apache/activemq/transport/discovery/
> Failover through the failover protocol ;-) We will use it too:
> core/src/main/java/org/apache/activemq/transport/failover/
> Master/slave we are writing...but will reuse some of the  
> infrastructure.
> 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

View raw message