Re: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
The serialization contract as dictated by the serialVersionID at which the class was fixed in 3.2 should be maintained. -- Scott Stark Chief Technology Officer JBoss Group, LLC Bill Burke wrote: I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
The 20% was for Local interfaces and it doesn't break compatibility. Sacha Labourey wrote: I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: vendredi, 12. septembre 2003 01:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: vendredi, 12. septembre 2003 01:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
You guys are talking about a 3.3 proxy talking to a 3.2 server? If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-group] revamping Invocation objects
On Fri, 2003-09-12 at 00:27, marc fleury wrote: You guys are talking about a 3.3 proxy talking to a 3.2 server? 3.2.1 proxy talking to 3.2.2 server or vice versa. If that is the case, it is not really relevant as most proxies are dynamically generated. Or are you talking about portability of interceptors working on the Invocation objects? Yes and the serialization of the Invocation object. The stability of 3.2 and its performance are priorities #1, 3.x will live for MANY years marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, September 11, 2003 6:22 PM To: Private list for internal JBoss Group discussion; Jboss-Dev Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects I'd rather not maintain something like that. What do you think? IMHO, we should guarantee over-the-wire compatibility only for a specific branch. over-the-wire compatibility should be breakable between major releases. Adrian Brock wrote: On Thu, 2003-09-11 at 23:00, Bill Burke wrote: Ok, I wouldn't be able to improve raw, over-the-wire, remote performance without breaking compatibility with older JBoss versions. Would it be possible to set a property that provides backwards compatibilty at serialization. Something similar to jmx 1.0 vs jmx 1.1 serialized forms? Regards, Adrian Bill Bill Burke wrote: Only problem here is that what I've done so far is not backward compatible with a previous version of JBoss. I guess this is important. correct? I can make it compatible, but it will be a tiny bit ugly. I did increase performance for noop local interface calls for SLSB by 20%. Adrian Brock wrote: Ideally there should be no hashmap for normal usage. Using the principle: you don't pay for what you don't use. Regards, Adrian On Thu, 2003-09-11 at 20:02, Bill Burke wrote: In our quest to improve performance, I'm doing a redesign of our Invocation object to minimize object creations and hash lookups. I'll base it on some of Sacha's and my own observations. Just wanted to give some heads up just in case somebody else was looking at this too. Bill -- Bill Burke Chief Architect JBoss Group LLC. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
