You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2010/05/27 01:55:55 UTC
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.
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 <jo...@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-subscribe@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-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, May 27, 2010 at 12:39 PM, Emmanuel Bourg <eb...@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-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Emmanuel Bourg <eb...@apache.org>.
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
Re: Size of the Java client
Posted by Martin Ritchie <ri...@apache.org>.
On 27 May 2010 00:55, Rajith Attapattu <ra...@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 <jo...@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-subscribe@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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Martin Ritchie <ri...@apache.org>.
On 27 May 2010 17:42, Emmanuel Bourg <eb...@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-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Emmanuel Bourg <eb...@apache.org>.
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
Re: Size of the Java client
Posted by Martin Ritchie <ri...@apache.org>.
On 27 May 2010 21:52, Robbie Gemmell <ro...@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:ritchiem@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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Size of the Java client
Posted by Robbie Gemmell <ro...@gmail.com>.
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:ritchiem@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-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Martin Ritchie <ri...@apache.org>.
On 27 May 2010 01:16, Sorin S. <ss...@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 <ra...@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
>>
>> Rajith
>>
>> On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer <jo...@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-subscribe@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-subscribe@qpid.apache.org
>>
>>
>
>
> --
> Sorin S
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by "Sorin S." <ss...@gmail.com>.
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 <ra...@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
>
> Rajith
>
> On Wed, Mar 31, 2010 at 2:51 PM, Joshua Kramer <jo...@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-subscribe@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-subscribe@qpid.apache.org
>
>
--
Sorin S
Re: Size of the Java client
Posted by Martin Ritchie <ri...@apache.org>.
On 27 May 2010 17:16, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, May 27, 2010 at 12:06 PM, Emmanuel Bourg <eb...@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.
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-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, May 27, 2010 at 12:06 PM, Emmanuel Bourg <eb...@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-subscribe@qpid.apache.org
Re: Size of the Java client
Posted by Emmanuel Bourg <eb...@apache.org>.
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.
Emmanuel Bourg