Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Commit it on a branch. -- Scott Stark Chief Technology Officer JBoss Group, LLC Hiram Chirino wrote: The change is too big for a patch. I'd rather commit on a branch. Another option is to refactor it some more so that it becomes part of the new module that Nathan is working on. Either way, please let me know which way you prefer it. I have completed most of my clean up and the jms and mdb unit tests are once again passing with flying colors. The mailing list does not seem to have received a couple of emails I sent a few days back. Is there something wrong with the mailing list? Regards, Hiram --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hiram, no one sits around for months without interacting with the day to day developers of JBoss Group and then decides to commit a large change without it being discussed. Some of what you have most likely has merit but it has to be reviewed so either submit it as a patch or commit it to a branch off of head so that it can be reviewed for incorporation. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Wednesday, July 09, 2003 12:16 AM To: [EMAIL PROTECTED] Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. There has been a skeleton since early Jun. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Where have you been the past year when Adrian and Scott have been fixing this buggy MQ implementation? You failed to keep up the old stuff so please don't make it sound like you're coming to the rescue. I'm not so sure I want a total refactoring of the old JMS in the remoting subsystem and the interceptor chains and such. The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. What I don't want is a CVS HEAD of the old JMS that doesn't look like the 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS HEAD that has been totally refactored. The old JMS needs to live a bit beyond 4.0's release and 4.0 will not be released until the late late fall, between Thanksgiving and Christmas. I guess what I'm saying is that a lot of users will still depend on the old JMS for at least another year and we need some to have fluidity between 3.2 and 4.0. We're already experiencing the pain of an unnecessary rewrite of the Entity Container that is making it difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to happen with a codebase that is going to be retired eventually anyways and that needs to live in depracated mode for awhile. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
The change is too big for a patch. I'd rather commit on a branch. Another option is to refactor it some more so that it becomes part of the new module that Nathan is working on. Either way, please let me know which way you prefer it. I have completed most of my clean up and the jms and mdb unit tests are once again passing with flying colors. The mailing list does not seem to have received a couple of emails I sent a few days back. Is there something wrong with the mailing list? Regards, Hiram On Fri, 2003-07-11 at 13:01, Scott M Stark wrote: Hiram, no one sits around for months without interacting with the day to day developers of JBoss Group and then decides to commit a large change without it being discussed. Some of what you have most likely has merit but it has to be reviewed so either submit it as a patch or commit it to a branch off of head so that it can be reviewed for incorporation. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Wednesday, July 09, 2003 12:16 AM To: [EMAIL PROTECTED] Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. There has been a skeleton since early Jun. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Where have you been the past year when Adrian and Scott have been fixing this buggy MQ implementation? You failed to keep up the old stuff so please don't make it sound like you're coming to the rescue. I'm not so sure I want a total refactoring of the old JMS in the remoting subsystem and the interceptor chains and such. The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. What I don't want is a CVS HEAD of the old JMS that doesn't look like the 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS HEAD that has been totally refactored. The old JMS needs to live a bit beyond 4.0's release and 4.0 will not be released until the late late fall, between Thanksgiving and Christmas. I guess what I'm saying is that a lot of users will still depend on the old JMS for at least another year and we need some to have fluidity between 3.2 and 4.0. We're already experiencing the pain of an unnecessary rewrite of the Entity Container that is making it difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to happen with a codebase that is going to be retired eventually anyways and that needs to live in depracated mode for awhile. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
I prefer it be commit on a branch. Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, July 11, 2003 4:32 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jeremy Boynes Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite The change is too big for a patch. I'd rather commit on a branch. Another option is to refactor it some more so that it becomes part of the new module that Nathan is working on. Either way, please let me know which way you prefer it. I have completed most of my clean up and the jms and mdb unit tests are once again passing with flying colors. The mailing list does not seem to have received a couple of emails I sent a few days back. Is there something wrong with the mailing list? Regards, Hiram On Fri, 2003-07-11 at 13:01, Scott M Stark wrote: Hiram, no one sits around for months without interacting with the day to day developers of JBoss Group and then decides to commit a large change without it being discussed. Some of what you have most likely has merit but it has to be reviewed so either submit it as a patch or commit it to a branch off of head so that it can be reviewed for incorporation. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Wednesday, July 09, 2003 12:16 AM To: [EMAIL PROTECTED] Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. There has been a skeleton since early Jun. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Where have you been the past year when Adrian and Scott have been fixing this buggy MQ implementation? You failed to keep up the old stuff so please don't make it sound like you're coming to the rescue. I'm not so sure I want a total refactoring of the old JMS in the remoting subsystem and the interceptor chains and such. The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. What I don't want is a CVS HEAD of the old JMS that doesn't look like the 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS HEAD that has been totally refactored. The old JMS needs to live a bit beyond 4.0's release and 4.0 will not be released until the late late fall, between Thanksgiving and Christmas. I guess what I'm saying is that a lot of users will still depend on the old JMS for at least another year and we need some to have fluidity between 3.2 and 4.0. We're already experiencing the pain of an unnecessary rewrite of the Entity Container that is making it difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to happen with a codebase that is going to be retired eventually anyways and that needs to live in depracated mode for awhile. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Antwort: RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. Don't work on a codebase that is going to be retired and needs to live in depracated mode for awhile. A refactoring isn't what is needed in the JMS subsystem. I don't want to be pessimistic, but it took quite a long time to stabilize the current JBossMQ. This is especially true for heavy load scenarios. The ongoing JMS rewrite hopefully will bring significant improvements, but first of all it has to proof stability and spec compliance before it is a valid alternative for production usage. Many JMS users will have to / want to stay with JBossMQ for quite a longer than maybe expected ! Therefore ongoing improvements of the existing JBossMQ code have quite a value ( atleast for me as a JMS user, who requires a stable and matured JMS plattform :-) Regards Ulf
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Wednesday, July 09, 2003 12:16 AM To: [EMAIL PROTECTED] Subject: Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. There has been a skeleton since early Jun. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Where have you been the past year when Adrian and Scott have been fixing this buggy MQ implementation? You failed to keep up the old stuff so please don't make it sound like you're coming to the rescue. I'm not so sure I want a total refactoring of the old JMS in the remoting subsystem and the interceptor chains and such. The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. What I don't want is a CVS HEAD of the old JMS that doesn't look like the 3.2 series since it will be much harder to migrate 3.2 fixes to a CVS HEAD that has been totally refactored. The old JMS needs to live a bit beyond 4.0's release and 4.0 will not be released until the late late fall, between Thanksgiving and Christmas. I guess what I'm saying is that a lot of users will still depend on the old JMS for at least another year and we need some to have fluidity between 3.2 and 4.0. We're already experiencing the pain of an unnecessary rewrite of the Entity Container that is making it difficult to merge fixes in 3.2 to 4.0. I don't want the same thing to happen with a codebase that is going to be retired eventually anyways and that needs to live in depracated mode for awhile. Nathan, Your doing great work in the peer based JMS arena. But have you formulated a game plan for the rewrite of general purpose implementation? Right now I'm going down the route of simplifying our current c/s implementation down enough so that we can start taking it apart more easily if required to add the needed features. If you still are up to merging fixes in 3.2 to HEAD that is fine. I'm not sure we want a full refactoring. Bill --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Wednesday, July 09, 2003 12:38 AM To: [EMAIL PROTECTED] Subject: RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: In line... Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub worked. That's better than starting from scratch. so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or the distribution as we move forward. You may be right. or wrong. The current JMS will ship until there is a better replacement. Do you plan to replace the current implementation with the peer based implementation you have been working on? No, the peer based implementation will only be a flavor. As you already know, multicast can't be used for everything. Bill --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub worked. That's better than starting from scratch. Enough of this already! You give credit where credit is due. Norbert Lataille did 80% of the work, you and David Maplesden did the 20% needed for a solid release, but the better than starting from scratch doesn't give credit. You may be right. or wrong. The current JMS will ship until there is a better replacement. Do you plan to replace the The current JMS rewrite by Nathan, Adrian, and Bela is going quite well and we will be replacing the old system in the fall. Don't work on a codebase that is going to be retired and needs to live in depracated mode for awhile. A refactoring isn't what is needed in the JMS subsystem. As scott asked you, please make sure you communicate with nathan, the lead on JMS implementation. Otherwise your work will fall by the wayside. Also the forums are a good place to sync up or ask for clarifications. marcf --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
And what interaction has there been with Nathan who originally responded to the rewrite query? -- Scott Stark Chief Technology Officer JBoss Group, LLC Hiram Chirino wrote: Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or the distribution as we move forward. Thanks, Nathan Phelps JMS Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, July 08, 2003 8:41 PM To: [EMAIL PROTECTED] Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. So it's time for me to start the engine again and make some needed improvements to the current JBossMQ implementation. Nathan, Your doing great work in the peer based JMS arena. But have you formulated a game plan for the rewrite of general purpose implementation? Right now I'm going down the route of simplifying our current c/s implementation down enough so that we can start taking it apart more easily if required to add the needed features. On Tue, 2003-07-08 at 23:00, Scott M Stark wrote: And what interaction has there been with Nathan who originally responded to the rewrite query? -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite
On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: In line... Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub worked. That's better than starting from scratch. so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or the distribution as we move forward. You may be right. or wrong. The current JMS will ship until there is a better replacement. Do you plan to replace the current implementation with the peer based implementation you have been working on? Regards, Hiram Thanks, Nathan Phelps JMS Lead JBoss Group, L.L.C. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, July 08, 2003 8:41 PM To: [EMAIL PROTECTED] Subject: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or performance. I just wanted to give provide an update on the development status of the original JBossMQ client-server JMS implementation. Here's a summary of what has changed: - It exclusively uses the remoting subsystem for client server communications. The existing IL subsystem has been removed. The 'async' remoting protocol allows two way communications solely over client sockets (this should allow applet/firewalled clients to connect to the server). Multiple JMS connections made by the client will also share a singe pool of sockets to communicate with the server. - Manually creating JBossMQ ConnectionFactory objects have been simplified since a remoting URI takes care setting up most of the connection options. - The server interceptors have been simplified since they now operate on a typeless invocations (it now matches the style of the other jboss interceptors) - The implementations for the p2p and pub/sub JMS API classes have been consolidated since that is the direction that the JMS 1.1 API is taking (being able to mix the us of p2p and pub/sub with in the same session). - Many (almost all) of the bug fixes/performance enhancements made in the 3.2 branch have been ported forward. - All the PMs except JDBC2 have been removed to make it easier to more quickly make enhancements to the persistence manager interface. I hope a cmp/jdo implementation can be created in the future. - the old org.jboss.mq.xml package that provided a simple xml dom was removed and all code that was using was changed to use dom4j instead. - JNDI Reference object handling was simplified (only StringRefs are used). - The sources were refactored so that the back-end messing server is much less coupled the javax.jms.* classes. The server side is still importing many of the JMSException classes, this can be cleaned up in the future. This might start to lead the way to allow this messaging server to support other messaging APIs (JavaSpaces?) Things to watch out for with this new version: - The jboss API to manually create ConnectionFactory and Destination objects has changed. Most users should not be affected since the JMS spec states that they should be using JNDI to get those objects. - Previous JBossMQ clients will not be able to connect to this new server version (since it is using remoting for communications). Those clients need to upgrade their jbossmq-client.jar. - The message format has changed so the new server will not be able to restore messages saved to persistence storage by the new server. I hope to commit the changes CVS in the next few days. I have 3 jms test cases that I still need to fix and then I still need to run the MDB test cases. Regards, Hiram -- /** * Hiram Chirino * Partner * Core Developers Network **/ --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps
