geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: gcache imlementation ideas[long]
Date Fri, 15 Sep 2006 18:40:08 GMT


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/

Failover through the failover protocol ;-) We will use it too:

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.

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

Mime
View raw message