I had this problem as well.
I read the whole file into memory and then deflated it, and then I encoded
it with Base64 (so, it could be parsed in XML), which actually made it
come out bigger than the original source.
All was fine until I passed it around the JMS setup and then I got some
serious grind going on. Even when I made it an asynch transfer.
I then decided as I was going to end up moving from 1mb files to 50mb and
in extreme cases 2GB files, I needed another approach. This is when I
started looking into Streams in ActiveMQ. I can tell you streams are not
explained very well and are not easy in ActiveMQ.
Basically you can stream the file onto the JMS queue, but it will be
broken up into many messages. So, far so good. The problem then appears
where you have to take the messages off the queue, one at a time and
create a new stream to write them out too. In my case another stream for
FTP, as I do not really want to write temp 2GB files on my base o/s
(windows). This is a real pain and not really documented anywhere
properly. Even in the ActiveMQ API there is no explanation of what the
stream classes do, let alone examples!
Sounds not a big deal?
Well this means you may have streams hanging around in memory, either
waiting to be used, in use or worse still hanging around and not being
disposed off!
Yep you will have to write the code to manage all of that and make sure
its thread safe.
If anyone has any ideas of how I could manage that process better with
API's out there and so, on it would be helpful?
Regards Rick
"Guillaume Nodet" <[EMAIL PROTECTED]>
22/08/2006 10:30
Please respond to servicemix-users
To: [email protected]
cc:
Subject: Re: Question about servicemix's run trip time
If you use 1 Mb size jms messages, you should try to minimize
unneeded jms roundtrips as much as possible.
(Also, I hope you turned off debug logging, which would be killing
performances).
I'm not sure how to consider the ratio of 1:3 you give.
It will mainly depend on what your components do.
The only thing you could really compare to, is when using jms
without ServiceMix.
What do you mean by "serialize average time" ?
How is this parameter computed ?
On 8/22/06, Sharon Yin <[EMAIL PROTECTED]> wrote:
> Hi,all,
> Does anybody have any idea about servicemix's run trip time?
> Recently, I've got some confusion about servicemix's performance.
> I implement some components as SE and deploy into servicemix,
> and configure some httpBC, JmsSenderBC, JmsInBinding BC,
> as well as using JCA container to fulfill our message driven
architecture.
> we see that the result is not so good in our performance test,
> the run time proportion of our all components to servicemix's components
is
> 1:3,
> which means that the servicemix's components run time takes 75% of total
> time.
>
> In addition, the max concurrent accessing number is 250 in our test
> environment,
> and serialized average time is 2.5s
> but when I use big message sized 1MB, the number reduce to 10, and
> serialized average time is 7s.
>
> I'm not quite sure if this is our components' coding low down the
> performance
> or it's because the frequent transformation between Normalized message
and
> jms message takes too much time.
>
> hi, Guillaume, any comment about this?
>
> Thanks,
> Sharon.
>
> _________________________________________________________________
> 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>
--
Cheers,
Guillaume Nodet
Direct Line Group Limited, registered in England
with number 2811437, registered office 3 Edridge
Road, Croydon, Surrey CR9 1AG. The following
companies are members of the Direct Line Group:
Direct Line Insurance plc, Direct Line Life
Insurance Company Limited, Direct Line Unit
Trusts Limited and Direct Line Financial Services
Limited, all of which are authorised and regulated
by the Financial Services Authority. All are
members of The Royal Bank of Scotland Group.
This email is intended for the addressee only and
may contain confidential, proprietary or legally
privileged information. If you are not the
intended recipient of this email you should
notify us immediately and delete it. You should
not copy, print, distribute, disclose or use any
part of it. We reserve the right to monitor and
record all electronic communications through our
networks. We cannot accept any liability for
viruses transmitted via this e-mail once it has
left our networks.
