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 09:25:34 GMT


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
>>>
>>

Mime
View raw message