geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: gcache imlementation ideas[long]
Date Fri, 15 Sep 2006 18:14:02 GMT
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 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