geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: gcache imlementation ideas[long]
Date Wed, 11 Oct 2006 21:44:09 GMT

I addressed the discussion about "what transport" do we use, a long time 
ago by creating an agnostic API to plug into.

this way, we can continue the "pluggability" of G, and not pushing any 
specific protocols.
but writing a custom one just for G doesn't sound like a sound solution

in addition to ehcache, I'd like to propose that we take a look at ASF's 
JCS(Java Cache System) which sits under the Jakarta umbrella.

and a performance report 
(could be outdated)

sorry about splitting up the gcache discussion, actually it was already 
split when we started talking about the transport a while back in this 
However, my take on it is that we should use code already written, while 
this is all really cool stuff to work on, creating a distributed cache 
from start is hard and takes a very long time. I would think the main 
goal is to get to JEE 5 right now.


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
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 9/13/2006

View raw message