RE: eliminating one or two in memory copies of the response payload

For me, it gave 10-15% speed improvement and a pretty good memory footprint improvement. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

RE: eliminating one or two in memory copies of the response payload

, 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 2573 46 32 04 69 D6 ED F3

retained collectible memory

RPC, so all the goop that cascades down from that is collectible.) This doesn't have much impact in isolated environments, but when you run a lot of threads or whatever, the longer those threads hold memory that would otherwise be collectible, the bigger the overall memory footprint. --

RE: eliminating one or two in memory copies of the response payload

e expected worst case difference is 5x the payload size, and the observed difference is consistently about 4.5x. In other words, the memory footprint improvement meets expectations. Sorry for the noise. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

RE: eliminating one or two in memory copies of the response payload

n it is parsing from one backed by a String. (It's possible that I've missed some in-memory copying in soap.jar before getting to the XML parsing, but that seems unlikely given the number of times I've step-debugged through this recently.) Anyhow, the good news is that the results for "stream" are even better than expected. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

MutableBoolean.equals() method?

just getting rid of it. Messing with "equals()" is a common source of confusion and bugs. Not that it's needed, but trivial patch below .sig. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3

Re: eliminating one or two in memory copies of the response payload

s if I can get an undistracted few hours over the next couple weeks. If I don't make it by then, my guess is I'll never get to it. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

eliminating one or two in memory copies of the response payload

where the state of the payload can be one of InputStream, byte[], or String, with on-demand conversion through that progression. I also believe I will be able to do this such that the non-usual cases won't suffer (they'll really just end up forcing the conversions on demand where they would

Re: SAXSource vs DocumentBuilder performance

he XML parser was Xerces 2.4.) -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

SAXSource vs DocumentBuilder performance

? -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

Re: nightly CVS snapshot from Sep 2003

s some grunt work that needs to be done to make that happen, I could probably contribute to it.) -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

nightly CVS snapshot from Sep 2003

The newest nightly snapshot of Apache SOAP is from 9 Sep 2003. Is that because there are no changes since then or does the nightly snapshot machine need a little grease? http://cvs.apache.org/dist/soap/nightly/ -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573

RE: date deserialization with trailing sign locales

e literal decimal point between seconds and milliseconds. Beats me if there are other issues lurking down there, but this is simpler in terms of changed lines of Apache SOAP code than my brute force parser. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

date deserialization with trailing sign locales

Integer.parseInt(dateString.substring(14, 16)); int second = Integer.parseInt(dateString.substring(17, 19)); int millis = 0; if (dateString.length() == 24) millis = Integer.parseInt(dateString.substring(20, 23)); Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT")); cal.set(year, month, day, hour, minute, second); cal.set(Calendar.MILLISECOND, millis); return cal.getTime(); } -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3

Re: Some performance measures

> Axis is SAX based .. Sorry, then. My mistake. I guess I must've misinterpreted some comments on the Axis list (which I don't follow as closely). -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: Some performance measures

ance mode. It's a bigger mystery to me why the Apache Axis folks didn't do SAX parsing from the start and not bother with DOM.]] -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- To unsubscribe, e-mail: <mailto:[EMA

Re: Some performance measures

> Client achievements are less significally - up 10-15% to current code, > or -8-9 sec. Probably client code was less affected... This is consistent with informal client-side comparisons I've done along the same lines. The last I did was with the nightly Apache SOAP from 2002-11-13. We saw a f

Re: optimizing write() and StringUtils.lineSeparator

>> I think in fact is possible to hardcode separator, since anyway we >> use it the internet, were we know nothing about other part we >> communicate to (either server or client). That should certainly be true because for both SMTP and HTTP the header line separator is platform-independent (CRLF p

RE: Java profilers

I've used it several times on the client side (it's scary how much memory is being churned in Java stuff :-). -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.

Re: thread local storage and EJBs

> "WJCarpenter" [EMAIL PROTECTED] writes: >> I believe using ThreadLocal will make the code technically ineligible >> for use by EJBs, but I don't know if there are any EJB containers >> which enforce that. > > Hmm .. interesting. I thought it was our

Re: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLParserUtils.java

> Yes, that would be the case with this approach. The better way > would be to use thread local storage .. I just talked to Bill Nagy and > he said he would look into committing a patch to change this part. > (He's familiar with thread local storage and I'm not.) I believe using ThreadLocal will m

Re: improving client performance tricks

> Our first design was simple - when you need to make a call, just create > a new one. However creation of a Call is not so light - further it will > also require to create additional DocumentBuilder, and > SOAPMappingRegistry, both not so light. I agree with this point. Some time ago, we switche

Re: TODO list

> I am not sure why Socket is used. It was used in the first version > checked into CVS > (http://cvs.apache.org/viewcvs.cgi/xml-soap/java/src/org/apache/soap/uti > l/net/HTTPUtils.java?rev=1.1&content-type=text/vnd.viewcvs-markup). > Maybe it was because HTTP is relatively easy to implement, or

any thoughts of a 2.3.2 point release?

There have been some very worthwhile fixes since 2.3.1, especially the recent performance patches from Pavel Ausianik (which I think will also save me about 10%). Anyone thinking of a 2.3.2 point release collecting up all of that? (If not, we'll just grab a CVS snapshot sometime, but that feels

persistent connections

nt, it's hard to structure your request with the aim of forcing an even or odd number of packet responses :-), this is likely to be a big problem with persistent connections hitting Apache servers. I would be really happy to have my nose rubbed in some obvious fix or workaround for this. -- [EMAIL

Re: setTcpNoDelay; why not true by default?

got about the same numbers. If I used them both together, I only got about 90% of the improvement I got if I used either individually. I didn't pursue an explanation. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- To unsubscribe,

Re: setTcpNoDelay; why not true by default?

text always inserts the delay and never reduces any network traffic. PS:- "Nagle" might actually be "Nagel". I can never remember. Sorry, Mr Nag[le][el]. :-) -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- T

Re: setTcpNoDelay; why not true by default?

There is a pretty good discussion of this stuff, specifically regarding Apache SOAP, in the paper "Latency Performance of SOAP Implementations". Here's the URL: They do a much nicer job than I can of describing the interaction of Nagle and TCP delayed ACK. -- [EMAIL PROTECTE

setTcpNoDelay; why not true by default?

OAP insiders will know to call SOAPHttpConnection.setTcpNoDelay(BooleanTRUE) and have better performance than the unwashed. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

HTTP/1.1

Is it my imagination, or was somebody talking a while back about doing a patch that provided HTTP/1.1 persistent connections for Apache SOAP 2.x? -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 -- To unsubscribe, e-mail: <mai