Chuck, 1. Yes, Please don't use it in production. See item #2 in your message :)
2. some tests fail (some some do fail intermittently even now) because of problems in the http stream reading problems. the full copy prevented a few problems but i still get random errors in security tests, especially on win32 under jrockit. So it is not stable. 3. Please don't waste time right now....Reason below. The long term plan is to use HttpCore in HttpComponents. See thread: http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=httpcomponents&q=b Again, Please don't use what exists now in production now :) Please ping/watch the httpcomponents guys and let us switch to that and then make it production ready. thanks, dims On 5/17/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Hi All, I'm interested in using SimpleHTTPServer in production because it simplifies installation and packaging and it is (or should be) lean and fast. The application is a dedicated SOAP service that does not need other web or application server facilities. To use SimpleHTTPServier, I need to make some extensions and revisions. I'd appreciate any feedback on these ideas and an indication of whether others would find the changes and features useful: SimpleHTTPServer declares that it is not intended for production use. Is there any fundamental reason for not using it in production? SimpleHTTPServer uses HTTPWorker as its request handler. When processing SOAP messages, HTTPWorker reads the entire message, writes it into a ByteArrayOutputStream, and converts this to a byte[] that is then wrapped in a ByteArrayInputStream. The ByteArrayInputStream is used as the actual stream that gets wrapped by a stax reader. This copying has several problems. It is uncontrollable so a flurry of large messages will exhaust the jvm's Xmx. It is inefficient. It seems to eliminate the opportunity to process the message by streaming. My app has some messages with very large payloads that are processed by streaming message receivers. I'd like to eliminate the copying in HTTPWorker but suspect it is there for a reason. Does anybody know why it would be important to read the entire message before processing it? If the only concern is http timeouts, there are other ways to manage this. I'd like to add facilities for assigning operations to a set of alternative thread pools than can be separately prioritized and resource-managed. E.g., small status-related requests would get immediate high-priority processing, while larger requests that will demand a lot of memory and cycles will wait for availability of a thread in a smaller pool. Any feedback appreciated. Thanks, Chuck
-- Davanum Srinivas : http://wso2.com/blogs/
