I addressed the discussion about "what transport" do we use, a long time
ago by creating an agnostic API to plug into.
http://marc.theaimsgroup.com/?l=geronimo-dev&m=115281186718399&w=2
http://people.apache.org/~fhanik/geronimo-cluster-api.zip
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.
http://jakarta.apache.org/jcs/index.html
and a performance report http://jakarta.apache.org/jcs/JCSvsEHCache.html
(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
thread.
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.
Filip
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
