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
--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
