Okay, I will shut up now :-P
--jason
On Sep 15, 2006, at 11:40 AM, Jeff Genender wrote:
Jason Dillon wrote:
Um, but does openwire handle discovery, failover, master/slave... ?
Discovery done through the mcast openwire transport ;-) We will
reuse it:
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-
core/src/main/java/org/apache/activemq/transport/discovery/
Failover through the failover protocol ;-) We will use it too:
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-
core/src/main/java/org/apache/activemq/transport/failover/
Master/slave we are writing...but will reuse some of the
infrastructure.
Jeff
--jason
On Sep 15, 2006, at 4:07 AM, Jeff Genender wrote:
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?
AMQ will perform well...its a great JMS implementation. But for the
initial shot I want to go for pure speed. AMQ uses openwire as its
transport engine, but it has a JMS impl behind it. I just want
openwire, with just a cache behind it...take out the middle-man,
JMS.
But with that said, we *will* make a JMS strategy and use
AMQ...but as a
client.
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.
But at the end of the day, its a JMS engine. Can we write
clustering
based nearly entirely on JMS? Yes. But then for those who do
not want
to use JMS, we are still stuck with the overhead of the protocol
and any
baggage that comes along with it. Lets use AMQ as a client to the
clustering (a pluggable strategy).
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...
Not reimplementing. See below...
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.
Sure it would. We are interested only in pushing objects and light
messages (eviction, etc). Adding our messages on top of the JMS
commands
minimally doubles the amount of data (from a messaging
perspective) that
needs to go over the wire.
I am a huge fan of AMQ and would really like to see G exploit its
network communications facilities as much as possible.
I am a big fan of it too...and we are exploiting it...look at the
commit
log...its a practical C/P of the openwire code from AMQ ;-) In
discussing this with Hiram, we agreed that the openwire protocol
would
be good for many projects, not just AMQ. So we are killing 2
birds with
one stone. We are pulling out openwire and trying to make it more
generic, so that it could live as its own jar so that many other
projects can use it.
IMO, this is the best way to get the most features for
clustering up and
running sooner, with less code to maintain.
I think that is what we are trying to do here to a large extent.
Great discussion! More! more!
--jason
