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