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:13:08 GMT
I will wait and see what you come up with first :-)


On Sep 15, 2006, at 2:25 AM, Jeff Genender wrote:

> Jason Dillon wrote:
>> 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
> Write it!  That would be awesome ;-)
> As a side note, shall we race?  TCP vs JMS? ;-) j/k
>> --jason
>> 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