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
