wjc> I'm developing an obsession with getting rid of unnecessary wjc> copies during response processing.
To refresh your memories, I'm working on a patch that will allow streaming the response payload directly into the XML parser inside Call.invoke(), and I think I can also have a real stream inside the DataSource returned by Message.receive(). A little while back, I reported time improvements of about 5% for this in single-threaded testing. Now that I've done more organized testing, the difference is more in the ballpark of 10-15% for time and 4-5x payload size difference in scratch memory footprint (a 100 byte response on the wire translates to a 100 character response in memory, which is 200 bytes in memory; the difference in the example would be 800-100 bytes). In other words, a respectable improvement in both factors. It's mostly easy to make it completely transparent to stream response payloads to the receiver, but it can't be 100% because of the following factors, which leads to a couple of upward compatibility questions for interested parties: * As I mentioned in my original message, there's one place inside Call.invoke where a scratch copy of the response is tucked away "just in case" for possible use in exception text. My guess is nobody really cares about that case. * SOAPContext contains a protected field "rootPartString" that holds a reference to the response payload as a String. The field is not referenced outside its class, so the only upward compatibility problem is for subclasses of SOAPContext. There are no subclasses of SOAPContext in the Apache SOAP distribution. There is also an accessor method, "getEnvelope", which returns the same thing. So, is this field (and the dozen or so other fields) protected for the benefit of subclasses, or was it just somebody's habit to code fields as protected? More importantly, does it matter if I get rid of that particular field? My guess is that it doesn't matter. * Same question as above for TransportMessage, except it contains two such protected fields. "bytes" is a reference to the payload as a byte[] and "envelope" is a reference to it as a String (yeah, I thought the same thing about that :-). There are no subclasses of TransportMessage in the Apache SOAP distribution. So, likewise, were those fields intentionally "protected", and does it matter if I get rid of them. Again, my guess is that it doesn't matter. * Class TransportMessage implements Serializable. Hrmmm? Any particular reason for this? My guess is that it's completely extraneous and a TransportMessage is never actually serialized (in the java.io.Serializable sense). The reason I make that bold claim is because one of the fields inside TransportMessage is a SOAPContext, and SOAPContext does *not* implement Serializable, which means any attempt to actually serialize TransportMessage would blow up. So, does this "implements Serializable" matter? As I said, my guess is not. (The reason I ask is because I want to add another field inside TransportMessage, and I don't want to go to the bother of properly implementing serialization in that referenced class.) Finally, a more general sort of question: What's the confidence in the Apache SOAP test code in detecting regression errors? The change I'm making is not conceptually complicated, but it is fairly invasive, mostly because of the use of the fields mentioned above. Not counting a new utility class, the unified patch is about 27k, and a lot of that is couple-of-lines changes scattered around. I'm pretty confident in being right for the code paths I test directly, but there are code paths I don't test at all (and perhaps am not even aware of). Is running the test code likely to shake out any problems? -- [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
