As Bela and I have recently discussed with Tom Elrod, we all think that exposing JavaGroups as a transport of the remoting framework is indeed the best approach. However, I struggle with how the client-server nature of the remoting framework maps to the client-client nature of mulicast. I think this can indeed be overcome. However, as Tom doesn't have much time to spend on it, I think the road I'm gong to go down is to code directly to JavaGroups right now, and abstract it later.
However, the real important point here FOR EVERYONE TO GET is that the multicast implementation is just ONE implementation of the client-side JMS interfaces. We will also support the traditional client-server based implementation that the new code is building toward. The only reason I'm even talking about the multicast stuff is because Bela showed me just how JavaGroups makes it so simple to implement and it will give us an opportunity to get something out the door in short order. Additionally, multicast will always provide better performance for pub/sub then a traditional client-server design. So for clients that want in-firewall messaging that is super fast, the multicast stuff will best serve their needs. For clients that need Internet messaging, etc. the traditional design will be used. We are VERY focused on building a best-of-breed JMS implementation. The current code causes us pain and that is all the motivation we need. I was very encouraged to talk to the guys last week and gather ideas. Andrian Brock is brilliant and has all sorts of ideas for the new JMS codebase that have all grown out of his dealings with the old codebase. We will not repeat the mistakes of the old codebase which is why we're starting anew from scratch. I'm going to get the project page on the website set up to better communicate the plan (which is something I should have done long ago) over the next week. Oh, and to address Marc's comment on the "reloaded" thing... that is just a code name for now--it sounds better then saying "rewrite." The branding is clearly JMS/JBoss. Thanks, Nathan Phelps JMS/JBoss Project Lead JBoss Group, L.L.C. Quoting Bill Burke <[EMAIL PROTECTED]>: > Nathan's design will not be based on JavaGroups, but will rather use > JavaGroups as one type of transport mechanism. I would rather see JBoss > Remoting used as an abstraction with JavaGroups as a plugin rather than > JavaGroups at the center of things. > > BUT....don't let this requirement hold you up from getting a first iteration > in place. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Bela > > Ban > > Sent: Monday, June 16, 2003 1:12 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > > > > > > Hi Ulf, > > > > > (2) message redelivery / message throttling clustering / failover > > > > > > since Nathan's design is based on JavaGroups, these issues are > > JavaGroups issues: > > - Message retransmission is handled by JavaGroups. > > - Failover: what do you understand by failover ? > > - Throttling: we are working on a multicast flow control protocol, JG > > currently ships with one, but it has a number of bugs and needs further > > work. I'm also working on a new flow control protocol. Also, note that > > you can run JG with TCP as transport, then you essentially have the > > classic JMS client-server implementation. > > > > > > > (3) messaging system monitoring / administration > > > > > > I there a way to participate in the your ongoing rewrite ? > > > > > > Give us some more time; Nathan essentially designed the serverless JMS > > last weekend... > > > > > > -- > > Bela Ban > > http://www.javagroups.com > > Cell: (408) 316-4459 > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: eBay > > Great deals on office technology -- on eBay now! Click here: > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
