RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Sorry but the "reloaded" brand is already used by another JBoss project managed by Thomas Aardal to allow "old" JBoss client jars to be used with newer JBoss releases ;) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: lundi, 16. juin 2003 21:08 > To: [EMAIL PROTECTED] > Subject: 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. > > > > 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
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
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
I'm pretty excited about the JavaGroups implementation. Should scale quite well. I also really liked the idea of the AppServer being just another subscriber for durable topics. Should be interesting how all this develops over the next few months. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bela > Ban > Sent: Monday, June 16, 2003 2:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite > > > Bill Burke wrote: > > > Nathan's design will not be based on JavaGroups, but will rather use > > JavaGroups as one type of transport mechanism. > > > Don't get all nervous; that's what I meant. 2 transports, one is the > traditional c/s, the other one is implemented using JavaGroups. > > > > I would rather see JBoss Remoting used as an abstraction with > > JavaGroups as a plugin rather than > > JavaGroups at the center of things. > > > Tom, Jeff, Nathan and I have tentatively scheduled JBoss bootcamp in > Atlanta to be the place and time for an in-depth discussion of whether > Remoting can accommodate a one-to-many paradigm in addition to a > one-to-one paradigm. > > Nathan already has a thin abstraction layer over the transport, for both > traditional and serverless design. > > > -- > 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
Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Bill Burke wrote: Nathan's design will not be based on JavaGroups, but will rather use JavaGroups as one type of transport mechanism. Don't get all nervous; that's what I meant. 2 transports, one is the traditional c/s, the other one is implemented using JavaGroups. I would rather see JBoss Remoting used as an abstraction with JavaGroups as a plugin rather than JavaGroups at the center of things. Tom, Jeff, Nathan and I have tentatively scheduled JBoss bootcamp in Atlanta to be the place and time for an in-depth discussion of whether Remoting can accommodate a one-to-many paradigm in addition to a one-to-one paradigm. Nathan already has a thin abstraction layer over the transport, for both traditional and serverless design. -- 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
RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
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
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
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
