Re: Size of the Java client
Le 27/05/2010 01:55, Rajith Attapattu a écrit : 532Kbuild/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0Kbuild/lib/plugins 1.4Mbuild/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308Kbuild/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Do you think it could be possible to split the qpid-common jar? A large part of this jar consists of the framing for the different versions of the protocol. By removing the 0-8, 0-9 and 0-91 classes the jar is reduced by 56%. I imagine there could be one jar per version, and the user would keep only those he needs. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: Size of the Java client
On Thu, May 27, 2010 at 12:06 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 27/05/2010 01:55, Rajith Attapattu a écrit : 532K build/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0K build/lib/plugins 1.4M build/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308K build/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Do you think it could be possible to split the qpid-common jar? A large part of this jar consists of the framing for the different versions of the protocol. By removing the 0-8, 0-9 and 0-91 classes the jar is reduced by 56%. I imagine there could be one jar per version, and the user would keep only those he needs. I was also thinking along the same lines. One of the key requirements for the Java client is to able to support multiple protocol versions. Splitting into multiple jars based on protocol versions should be ok as long as we preserve that. The default client should include all jars, but in documentation we could mention that they can just copy only the jars they are interested in. I think the same can be done for the transports as well. Since 0-10 client doesn't use mina, anybody who is only interested in 0-10 can easily get rid of the mina jars. Another more important thing to do is to have look at all the classes in common and get rid of classes that are not used. Also if classes are only used on the broker side, then they should be moved to the broker module. Emmanuel Bourg -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
Le 27/05/2010 02:35, Martin Ritchie a écrit : Don't for get to count your favourite slf4j binding to make the total size of a usable client. SLF4J 1.6 has been released earlier this month. The bindings are now optional and you can run with just the base jar (24K only). Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: Size of the Java client
Le 27/05/2010 02:32, Martin Ritchie a écrit : I've been swamped and hadn't had the chance, I'll make a effort this weekend as I'd like to see us using a somewhat more recent MIna. We can easily get rid of backport-util by putting the dummy Java.15 version in. It simply proxies the Java concurrent classes rather than using the 1.4 compatible approach. I updated the patch in QPID-2498 if you want to review it this weekend. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: Size of the Java client
On Thu, May 27, 2010 at 12:39 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 27/05/2010 02:35, Martin Ritchie a écrit : Don't for get to count your favourite slf4j binding to make the total size of a usable client. SLF4J 1.6 has been released earlier this month. The bindings are now optional and you can run with just the base jar (24K only). Emmanuel Bourg Yes, I mentioned this on the java logging thread last week. I plan to upgrade to SLF4J 1.6 before the next release. I believe the consensus was to ship with no binding and the 1.6 version is perfect as it will just print a message and default to noop if no binding is present. -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
On 27 May 2010 17:42, Emmanuel Bourg ebo...@apache.org wrote: Le 27/05/2010 02:32, Martin Ritchie a écrit : I've been swamped and hadn't had the chance, I'll make a effort this weekend as I'd like to see us using a somewhat more recent MIna. We can easily get rid of backport-util by putting the dummy Java.15 version in. It simply proxies the Java concurrent classes rather than using the 1.4 compatible approach. I updated the patch in QPID-2498 if you want to review it this weekend. Cheers will take a look. Emmanuel Bourg -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
On 27 May 2010 17:16, Rajith Attapattu rajit...@gmail.com wrote: On Thu, May 27, 2010 at 12:06 PM, Emmanuel Bourg ebo...@apache.org wrote: Le 27/05/2010 01:55, Rajith Attapattu a écrit : 532Kbuild/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0Kbuild/lib/plugins 1.4Mbuild/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308Kbuild/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Do you think it could be possible to split the qpid-common jar? A large part of this jar consists of the framing for the different versions of the protocol. By removing the 0-8, 0-9 and 0-91 classes the jar is reduced by 56%. I imagine there could be one jar per version, and the user would keep only those he needs. I was also thinking along the same lines. One of the key requirements for the Java client is to able to support multiple protocol versions. Splitting into multiple jars based on protocol versions should be ok as long as we preserve that. The default client should include all jars, but in documentation we could mention that they can just copy only the jars they are interested in. I think the same can be done for the transports as well. Since 0-10 client doesn't use mina, anybody who is only interested in 0-10 can easily get rid of the mina jars. Another more important thing to do is to have look at all the classes in common and get rid of classes that are not used. Also if classes are only used on the broker side, then they should be moved to the broker module. Ideally I'd like to see us have a very small qpid-common that is basically our interfaces between protocol and transports. Then we can drop in OSGi-fied protocol jars and transports such as Mina/Growl or our own transport. I'm hoping to find time to write up the push to modularise the java broker. Just not enought time right now. Emmanuel Bourg -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Size of the Java client
I'm not sure this would work actually, looking that the project page it says the 1.5 dummy isn't compatible with 1.6+ JVM's Robbie -Original Message- From: Martin Ritchie [mailto:ritch...@apache.org] Sent: 27 May 2010 01:33 To: dev@qpid.apache.org Subject: Re: Size of the Java client snip We can easily get rid of backport-util by putting the dummy Java.15 version in. It simply proxies the Java concurrent classes rather than using the 1.4 compatible approach. /snip - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
On 27 May 2010 21:52, Robbie Gemmell robbie.gemm...@gmail.com wrote: I'm not sure this would work actually, looking that the project page it says the 1.5 dummy isn't compatible with 1.6+ JVM's :( how disappointing. Robbie -Original Message- From: Martin Ritchie [mailto:ritch...@apache.org] Sent: 27 May 2010 01:33 To: dev@qpid.apache.org Subject: Re: Size of the Java client snip We can easily get rid of backport-util by putting the dummy Java.15 version in. It simply proxies the Java concurrent classes rather than using the 1.4 compatible approach. /snip - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
If we upgrade to mina 1.1.7 then we could easily get rid of backport-util-concurrent.jar. With the changes I proposed in QPID-2629 we reduce this a bit further as well. For the client release, if we don't ship the tests then with the above changes we could get somewhere close to ~ 2.3 MB. Here's the break down. 532Kbuild/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0Kbuild/lib/plugins 1.4Mbuild/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308Kbuild/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Rajith On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer j...@globalherald.net wrote: would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
Hi, +1 for the idea of getting rid of backport-util-concurrent jar As a curiosity, did anybody run any kind of test with Emmanuel's patch for upgrading to Mina 1.1.7 - is this change bringing any noticeable improvement? Thanks, Sorin On Thu, May 27, 2010 at 12:55 AM, Rajith Attapattu rajit...@gmail.comwrote: If we upgrade to mina 1.1.7 then we could easily get rid of backport-util-concurrent.jar. With the changes I proposed in QPID-2629 we reduce this a bit further as well. For the client release, if we don't ship the tests then with the above changes we could get somewhere close to ~ 2.3 MB. Here's the break down. 532Kbuild/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0Kbuild/lib/plugins 1.4Mbuild/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308Kbuild/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Rajith On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer j...@globalherald.net wrote: would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Sorin S
Re: Size of the Java client
On 27 May 2010 01:16, Sorin S. ssu...@gmail.com wrote: Hi, +1 for the idea of getting rid of backport-util-concurrent jar As a curiosity, did anybody run any kind of test with Emmanuel's patch for upgrading to Mina 1.1.7 - is this change bringing any noticeable improvement? I've been swamped and hadn't had the chance, I'll make a effort this weekend as I'd like to see us using a somewhat more recent MIna. We can easily get rid of backport-util by putting the dummy Java.15 version in. It simply proxies the Java concurrent classes rather than using the 1.4 compatible approach. Thanks, Sorin On Thu, May 27, 2010 at 12:55 AM, Rajith Attapattu rajit...@gmail.comwrote: If we upgrade to mina 1.1.7 then we could easily get rid of backport-util-concurrent.jar. With the changes I proposed in QPID-2629 we reduce this a bit further as well. For the client release, if we don't ship the tests then with the above changes we could get somewhere close to ~ 2.3 MB. Here's the break down. 532K build/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0K build/lib/plugins 1.4M build/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308K build/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Rajith On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer j...@globalherald.net wrote: would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Sorin S -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
On 27 May 2010 00:55, Rajith Attapattu rajit...@gmail.com wrote: If we upgrade to mina 1.1.7 then we could easily get rid of backport-util-concurrent.jar. With the changes I proposed in QPID-2629 we reduce this a bit further as well. For the client release, if we don't ship the tests then with the above changes we could get somewhere close to ~ 2.3 MB. Here's the break down. 532K build/lib/qpid-client-0.7.jar 32K build/lib/mina-filter-ssl-1.0.1.jar 4.0K build/lib/plugins 1.4M build/lib/qpid-common-0.7.jar 24K build/lib/qpid-all.jar 308K build/lib/mina-core-1.0.1.jar 28K build/lib/geronimo-jms_1.1_spec-1.0.jar 16K build/lib/slf4j-api-1.4.0.ja Don't for get to count your favourite slf4j binding to make the total size of a usable client. Rajith On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer j...@globalherald.net wrote: would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
Rafael Schloming a écrit : I'm generally in favor of examining and reducing our dependencies where possible. We haven't done this in a long time, so I wouldn't be surprised if they could be trimmed a bit. Do you have a specific size/configuration in mind? Are you looking at embedded usage or something? I'm not specifically looking at an embedded usage, that will be for a desktop application, but I generally pay attention to the size of the dependencies. I would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) Also less dependencies helps avoiding dependency hell. For example I also use backport-util-concurrent on my project, but at version 3.1. I'm not confident the Qpid Java client would work fine since it depends on the 2.2 version. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
