That's pretty kool. Did you use any streaming to avoid putting the data in memory and building the tree? Or did you just more or less follow the same steps in the mtom tutorial?
Robert On 10/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi > > We were in similar situation we were planning to transfer 1GB file as SOAP > as attachment. > > 1) Axis2 give pretty good support using MTOM and SWA for transferring any > size file. 1GB file transferred in 67sec on local network. File caching > feature is great. > 2) But it is not good idea to transfer SOAP with such large attachment. We > also hit some our app server & service bus handling limitation. So we > decided to process data in chunk. We get file data in chunk and till we get > all data correctly we dont send confirm to end point (which really delete > file on source system . End of our getFile operation / confirming file > received at server ). Same way on reverse we put data in chunk to some temp > file on destination endpoint. after placing all data at end we rename it to > required file. > > Let me know your thoughts > > Regards > Yogesh Dhake > > > > *"Walker, Jeff" <[EMAIL PROTECTED]>* > > 10/22/2007 11:46 AM Please respond to > axis-user@ws.apache.org > > To > <axis-user@ws.apache.org> cc > > Subject > RE: Best way to realize stateful servicesarchitecturewithmassivedata? > > > > > > > Michele, > I'm not sure JMS is a viable alternative if large amounts of data are > transferred. That statement would imply there is some sort of size > cutoff. There isn't. Just remember, that with JMS you can have persisted > queues and then all of that data would have to be stored temporarily. > Personally, I think some of the lessons from JMS (message queuing in > general) can be applied to web services; keep the msgs as small as > possible. > > Large data transfer (across the network) is a serious problem. There is > no easy solution that I've seen. Having said that, there are quite a few > posters who have used attachments with their web services. I have used > the older DIME format, but other posters have used the newer MTOM. I > would be interested to see what their performance was like, with large > files (ie. around a Gigabyte, say). Since MTOM chunks up the files, > transferring any sized file should theoretically be possible. > > Does anyone have any opinions on using MTOM for transferring Gb and and > multi-Gb files?? > -jeff > > > > > -----Original Message----- > From: Michele Mazzucco [mailto:[EMAIL PROTECTED] > Sent: Monday, October 22, 2007 11:21 AM > To: axis-user@ws.apache.org > Subject: RE: Best way to realize stateful > servicesarchitecturewithmassivedata? > > Jeff, > > I mentioned JMS as possible choice if one has to transfer large amount > of data since it is asynchronous. > > Michele > > On Mon, 2007-10-22 at 11:10 -0400, Walker, Jeff wrote: > > You mentioned WS over JMS. Again, added delay, since another protocol > > layer is employed. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > * > ====================================================================================================== > This transmittal and any attachments may contain confidential, privileged > or sensitive information and is solely for the use of the intended > recipient. If you are not the intended recipient, you are hereby notified > that you have received this transmittal and any attachments in error and any > review, dissemination, distribution or copying thereof is strictly > prohibited. If you have received this transmittal and any attachments in > error please notify the sender and immediately destroy the message and all > its attachments. Any opinions herein expressed may be those of the author > and not necessarily of Mizuho Corporate Bank, Ltd., Mizuho Corporate Bank > (USA), Mizuho Securities USA Inc. or any other affiliates of Mizuho > Financial Group ("Mizuho"). Mizuho accepts no responsibility for the > accuracy or completeness of any information herein contained. > E-Mail received by or sent from officer of Mizuho Securities USA Inc. > (which is a registered U.S. broker-dealer and the entity through which > Mizuho generally conducts its investment banking, capital markets, and > securities business in the United States) is electronically archived and > recorded and is subject to review and monitoring by and/or disclosure to > persons other than the recipient, including (but not limited to) Mizuho > Securities USA Inc. supervisory personnel. Such communications may be > produced to regulatory authorities or others with legal rights to the > information.* >
