Yes we are using DIME type attachments. You dont have to put attachments as 
part of WSDL.
   
  Follow the article on how to do attachments. Do it as "manual attachments" 
verses defining in the method signature i.e. in WSDL
   
  Ss
   
  
Lyman <[EMAIL PROTECTED]> wrote:
  Thank you very much for the most informative reply. As you can see from the 
invoke method statement, the wsdl has defined the attachments as base64 encoded 
byte arrays (actually axis does the encoding). I have not control over the wsdl 
definitions because I am sending the files to an external service. I need to 
read the articles in depth to fully understand what is happening but are you 
saying that I would be able to use the dime type for the attachments and still 
comply with the wsdl? 

Sorry for the naive questions.

Thanks
Lyman


ss shah wrote:
> 
> I have successfully sent 20M attachments.
> 
> My implementation is based on the articles in this newsgroup
> 
> http://mail-archives.apache.org/mod_mbox/ws-axis-user/200411.mbox/[EMAIL 
> PROTECTED]
> 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg08732/Fear_of_Attachments.pdf
> 
> 
> We have done heavy traffic test (lasting upto 4 hours) for messages with 
> 1M attachments and did not see any memory issues.
> 
> We are using APache Axis 1.4, jboss 4.0.3 sp1
> 
> 
> 
> */Lyman /* wrote:
> 
> I appreciate any help or guidance you may provide. I am trying to
> determine if I am trying to solve a solvable problem or should I
> pursue other methods to overcome the problem.
> 
> Particulars:
> Apache/1.3.27 Ben-SSL/1.48 (Unix) Debian GNU/Linux mod_jk/1.2.5
> mod_perl/1.27
> tomcat4_4.1.28-1
> Axis 1.1
> java version "1.4.2_02"
> Linux version 2.4.22 (gcc version 2.95.4 20011002 (Debian
> prerelease)) #1 Wed Oct 1 14:41:07 EDT 2003
> 
> 
> Overview: Sending data to a external service, sometimes the data
> includes file attachments. The external service requested we convert
> from a get file attachments (sending a url for the file) to a push
> file attachments process. The conversion has been working just fine
> but when we tried to send a file larger than 4 mb we started getting
> java.lang.OutOfMemoryError. I increased the machine specs from 64mb
> ram 500 mhz pII to a P4 1.3ghz 1gb ram. Error now takes much less
> time to manifest itself but still occurs. The error usually occurs
> when tomcat is in this statement:
> 
> java.lang.Object _resp = _call.invoke(new java.lang.Object[]
> {pvarSspNumber, pvarContractNumber, pnumIdrNumber, pvarRevision,
> pvarUrgency, pvarItemNumber, pvarDescription, pvarIsPartial,
> pvarWorkItemParagraph, pvarReportType, pvarRecommendation,
> pvarAnswerMandatory, pvarReportAction, pvarResponseReqByDt,
> pKtrCertificateNm, pvarBriefTx, pvarKtrMatl, pvarKtrCtLastNm,
> pvarLocation, pnumCostProposal, pvarKtrComments, ptypAttachMetaBlob});
> 
> 
> I have reviewed the archives and found much talk about sending files
> with soap messages and how the file size is usually restricted. I
> have also seen talk of being able to send 20mb files. The outside
> service confirms they are able to send 9mb files using .net routines.
> 
> My question is this I guess, is it reasonable to think I should be
> able to send files larger than 4mb. If it is reasonable, then what
> can I do to accomplish that. Those that are sending 20mb files, what
> did you have to do to be able to accomplish the task?
> 
> Would setting the STREAMING_PROPERTY to true for the _call object
> help? (I do not know how to set this other than the setStreaming
> method.) Is there a way to tell axis to use streaming all the time?
> 
> I have tried using -Xmx1500m but did not see any change in behavior.
> 
> I am new to tomcat and axis but need to maintain this application
> that was written by someone else.
> 
> Again, I am most appreciative of any assistance in resolving the
> problem. If anyone on the list would be able to help me have the
> capability to send larger files but would like to be paid for that
> assistance, please contact me off list.
> 
> This is my first post to the list so thanks for you patience and
> understanding if I fall short of providing the information needed to
> provide help.
> 
> Lyman
> 
> 
> ---------------------------------------------------------------------
> 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]



       

Reply via email to