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
