Yo! I am working on a summary of this issue for a project I am involved in. Here are my questions to the list
1. Is the following still accurate? 2. Are there better quantifications of this? 3. Are there plans to try and better these limits, or is that much of an issue for people? 4. Are there better workarounds? Any advice cheerily accepted! -- Jeff ************************ There is no theoretical limit, but in practice this is different. Essentially the problem is that XML is extremely verbose, so that even smallish messages tend to grow. Since XML is slow to parse, this tends to make things crawl as well. The following are typical comments. (quotes from the AXIS user list and refer to version 1.1, which is the current) ============== I did some quick experiments with an rpc/encoded SOAP call that returned an array of objects. Each object has a smattering of data: a string, a few numbers. What I found was that Axis could handle 10,000 objects in the response reasonably but not 100,000 objects. The client was the bottleneck. I also saw evidence of some O(n^2) scaling in the size of the array. Each element in my test array has 40 bytes of real data in ASCII. The XML encoding ballooned it out to 500 bytes. So 100,000 elements is 50 megs of message. It took the client over 15 minutes to parse this! ============== We ahve had large message problems and are moving to soap with attachments now. Messages of about 800k where causing a lot of problems even after increasing the server memory allocation to about 256M, but it does appear that the problems are due to a mixture of large content size and a large number of XML elements (or object encoded XML elements). We send large messages from client to server and server to client, so we need to address the problem as 256M clients are a bit fat :) The workaround is to use SOAP attachments, but this also has limitations. People routinely send 10 Mb or so files, but too much above that leads to this type of post ============== Due to the problems with lost memory using base 64 encoded images in services yesterday I tried today to use attachments. It works fine if I attach files (tif images) with file size not greater than 11-12 MB. Files with sizes greater than 12MB were not written from the server service. Are the any limitations for the filesize or any possible solutions for files with 20, 30 or more MB.
