Jason Dillon wrote: > 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 >
Write it! That would be awesome ;-) As a side note, shall we race? TCP vs JMS? ;-) j/k > --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 >>> >>
