geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
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

View raw message