On 9/15/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Jason Dillon wrote: > Um, but does openwire handle discovery, failover, master/slave... ? Discovery done through the mcast openwire transport ;-) We will reuse it:
Discovery is simple enough..
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/discovery/ Failover through the failover protocol ;-) We will use it too:
Failover is protocol specific, since you are not using the ActiveMQ protocol, just the same transport pattern, you will may to re-implement parts of the failover protocol. The bits where on failover client state is re-established with the server. So most of the works would be in the StateTracker object that the failover protocol uses.
http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/failover/ Master/slave we are writing...but will reuse some of the infrastructure.
For activemq M/S is a bit simplistic where the client uses the failover protocol and the master broker handles replicating state to the slave. Regards, Hiram
Jeff > > --jason > > > On Sep 15, 2006, at 4:07 AM, Jeff Genender wrote: > >> >> >> 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
-- Regards, Hiram Blog: http://hiramchirino.com
