Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Ulf, Our primary goal with JMS reloaded is to address the items you highlighted. Adrian and I had a very interesting discussion about number one, and Bill and I discussed clustering a bit in SF last week. So we are certainly focused on number 1 and 2. Number 3 is less of a concern to me right now. Overall, however, our goals are certainly aligned. I'm going to be putting together a formilized project plan next week that I'll publish on the website. From it, you and I should be able to determine where you have the time and skill to contriute the most. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. Quoting [EMAIL PROTECTED]: Hi Nathan, thanks for the information. I already have seen your first CVS code. Is there any further information available about the planed design and feature set ? You already gave some interesting insights about the p2p feature. When using jms in an enterprise production environment - as we would like to do - the following aspects are of even more importance ( and most of these isues are not handled very well in the current JBossMQ implementation ) (1) EFFICIENT handling of large / high numbers of PERSISTENT topic and queue messages (2) message redelivery / message throttling clustering / failover (3) messaging system monitoring / administration I there a way to participate in the your ongoing rewrite ? Regards Ulf Nathan Phelps [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 15.06.2003 00:00 Bitte antworten an jboss-development An: [EMAIL PROTECTED] Kopie: Thema: RE: [JBoss-dev] JBossMQ rewrite JBossMQ?the current code base?will continue to ship with JBoss 3.2 which is, and will remain for some time, the production version. Therefore, making changes to the current code base IS NOT worthless. However, I am working on a brand new implementation with assistance from Adrian, Bela, Bill, Tom Elrod, and Troy Daley. The framework code has recently been checked in to the jboss-jms module in CVS. It is early, but a start. In addition to the traditional client-server oriented JMS we're working on, at Bela's suggestion, I was able to implement a pure p2p implementation of the JMS topic messaging domain that does non-durable subscribers over JavaGroups. At Bill's request, we're going to get this code out there quickly (July). To my knowledge this will be the first pure p2p (server-less) JMS implementation in open source and it will provide very fast in-firewall publish and subscribe over multicast. Thanks, Nathan Phelps JMS/JBoss (Reloaded) Project Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 13, 2003 4:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBossMQ rewrite Can anyone give me some informations about the current state of the announced rewrite of JBossMQ for JBoss 4 ? Does it still make sense to implement needed features on the current JBossMQ implementation ? I don't want to spend time on something that gets nuked in short time :-) Regards Ulf --- 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
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
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. BUTdon'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
