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 03:23:49 GMT
Aight... well, lets see the interfaces and the socket impl and I will  
write the jms impl and see which fairs better with the most features :-P


On Sep 14, 2006, at 8:17 PM, Kevan Miller wrote:

> I'm with Jeff on this one...
> I've seen this done w/ JMS. However, there's so much JMS overhead  
> that you don't need (message formats, persistent messages, delivery  
> semantics, etc).
> I recall Jeff was talking to Hiram about ActiveIO -- that's the  
> more appropriate way to go. Reuse common technology, but not all of  
> AMQ.
> --kevan
> On Sep 14, 2006, at 6:26 PM, 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?
>>> 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.
>> 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...
>> 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.
>> I am a huge fan of AMQ and would really like to see G exploit its  
>> network communications facilities as much as possible.
>> IMO, this is the best way to get the most features for clustering  
>> up and running sooner, with less code to maintain.
>> --jason

View raw message