You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2009/05/14 14:34:44 UTC
Peformance on socket reads
This post is a follow-on to my "performance with many small requests"
thread from a couple days ago.
I have been watching my app, and taking thread dumps when things seem to
be running a bit slower than I would like. Right now, the biggest
bottleneck seems to be on the POST data read. Here is the thread dump
of interest (there are several identical ones in my full dump):
[2009-05-13 15:49:50] [info] "http-1024-Processor11"
[2009-05-13 15:49:50] [info] daemon
[2009-05-13 15:49:50] [info] prio=6 tid=0x26c97858
[2009-05-13 15:49:50] [info] nid=0xe18
[2009-05-13 15:49:50] [info] runnable
[2009-05-13 15:49:50] [info] [0x2761f000..0x2761fa64]
[2009-05-13 15:49:50] [info] at
java.net.SocketInputStream.socketRead0(Native Method)
[2009-05-13 15:49:50] [info] at
java.net.SocketInputStream.read(Unknown Source)
[2009-05-13 15:49:50] [info] at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:747)
[2009-05-13 15:49:50] [info] at
org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:777)
[2009-05-13 15:49:50] [info] at
org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:115)
[2009-05-13 15:49:50] [info] at
org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:712)
[2009-05-13 15:49:50] [info] at
org.apache.coyote.Request.doRead(Request.java:423)
[2009-05-13 15:49:50] [info] at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:283)
[2009-05-13 15:49:50] [info] at
org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:404)
[2009-05-13 15:49:50] [info] at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:298)
[2009-05-13 15:49:50] [info] at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:192)
[2009-05-13 15:49:51] [info] at
eddsrv.EddRcvr.processRequest(EddRcvr.java:198)
[2009-05-13 15:49:51] [info] at eddsrv.EddRcvr.doPost(EddRcvr.java:99)
[2009-05-13 15:49:51] [info] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
[2009-05-13 15:49:51] [info] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
[2009-05-13 15:49:51] [info] at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
[2009-05-13 15:49:51] [info] at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
[2009-05-13 15:49:51] [info] at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
[2009-05-13 15:49:51] [info] at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
[2009-05-13 15:49:51] [info] at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
[2009-05-13 15:49:51] [info] at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
[2009-05-13 15:49:51] [info] at java.lang.Thread.run(Unknown Source)
[2009-05-13 15:49:51] [info]
The line eddsrv.EddRcvr.processRequest(EddRcvr.java:198) points to my
InputStream.read() line. All these variables are declared locally in
the method doing the work, not at the class level, so there is no
synchronization needed on them. This method is called from the doPost()
method of the servlet class.
Here are a few code lines for context setting:
req is my HttpServletRequest
iStream is a ServletInputStream
Then I have:
len = req.getContentLength();
b = new byte[ len ];
iStream = req.getInputStream();
/* this is the line 198 that the above thread dump is waiting for: */
strLen = iStream.read( b, 0, len );
iStream.close();
And then I convert b to a string and finish processing. Is there
anything stupid I'm missing that would cause the .read() to be slow? Or
is it just that my OS tcp/ip stack and/or network infrastructure appear
to be slow? I did quite a bit of reading on InputStream performance, it
couldn't find any suggestions to improve on what I've already got (the
biggest one was to read the whole thing at once rather than
byte-by-byte, and I'm already doing that).
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by David kerber <dc...@verizon.net>.
Rainer Jung wrote:
> On 14.05.2009 14:34, David kerber wrote:
>
>>
...
>> req is my HttpServletRequest
>> iStream is a ServletInputStream
>>
>>
>> Then I have:
>>
>> len = req.getContentLength();
>> b = new byte[ len ];
>> iStream = req.getInputStream();
>> /* this is the line 198 that the above thread dump is waiting for: */
>> strLen = iStream.read( b, 0, len );
>> iStream.close();
>>
>>
>> And then I convert b to a string and finish processing. Is there
>> anything stupid I'm missing that would cause the .read() to be slow? Or
>> is it just that my OS tcp/ip stack and/or network infrastructure appear
>> to be slow? I did quite a bit of reading on InputStream performance, it
>> couldn't find any suggestions to improve on what I've already got (the
>> biggest one was to read the whole thing at once rather than
>> byte-by-byte, and I'm already doing that).
>>
>
> socketRead0() most likely is really waiting for data to arrive. So now
> that you have an indication your performance is restricted by network,
> go ahead, install Wireshark and sniff a little traffic to verify, that
> your clients are really slow in sending the data (or invalidate that
> theory).
>
> Caution: you should do a couple of thread dumps and verify, that the
> code is waiting in socketRead0() in nearly all cases. Of course it's
> always possible that it is pure coincidence in a single dump.
>
Yes, I've taken several dumps over a couple of days, and multiple
instances of this one are always there. I'm pursuing the network issues
in parallel with my any possible issues with my code.
So my code looks reasonable in that respect?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by Rainer Jung <ra...@kippdata.de>.
On 14.05.2009 14:34, David kerber wrote:
> This post is a follow-on to my "performance with many small requests"
> thread from a couple days ago.
>
> I have been watching my app, and taking thread dumps when things seem to
> be running a bit slower than I would like. Right now, the biggest
> bottleneck seems to be on the POST data read. Here is the thread dump
> of interest (there are several identical ones in my full dump):
>
> [2009-05-13 15:49:50] [info] "http-1024-Processor11"
> [2009-05-13 15:49:50] [info] daemon
> [2009-05-13 15:49:50] [info] prio=6 tid=0x26c97858
> [2009-05-13 15:49:50] [info] nid=0xe18
> [2009-05-13 15:49:50] [info] runnable
> [2009-05-13 15:49:50] [info] [0x2761f000..0x2761fa64]
> [2009-05-13 15:49:50] [info] at
> java.net.SocketInputStream.socketRead0(Native Method)
> [2009-05-13 15:49:50] [info] at
> java.net.SocketInputStream.read(Unknown Source)
> [2009-05-13 15:49:50] [info] at
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:747)
>
> [2009-05-13 15:49:50] [info] at
> org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:777)
>
> [2009-05-13 15:49:50] [info] at
> org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:115)
>
> [2009-05-13 15:49:50] [info] at
> org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:712)
>
> [2009-05-13 15:49:50] [info] at
> org.apache.coyote.Request.doRead(Request.java:423)
> [2009-05-13 15:49:50] [info] at
> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:283)
>
> [2009-05-13 15:49:50] [info] at
> org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:404)
> [2009-05-13 15:49:50] [info] at
> org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:298)
> [2009-05-13 15:49:50] [info] at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:192)
>
> [2009-05-13 15:49:51] [info] at
> eddsrv.EddRcvr.processRequest(EddRcvr.java:198)
> [2009-05-13 15:49:51] [info] at eddsrv.EddRcvr.doPost(EddRcvr.java:99)
> [2009-05-13 15:49:51] [info] at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> [2009-05-13 15:49:51] [info] at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> [2009-05-13 15:49:51] [info] at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> [2009-05-13 15:49:51] [info] at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>
> [2009-05-13 15:49:51] [info] at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>
> [2009-05-13 15:49:51] [info] at java.lang.Thread.run(Unknown Source)
> [2009-05-13 15:49:51] [info]
>
>
>
>
> The line eddsrv.EddRcvr.processRequest(EddRcvr.java:198) points to my
> InputStream.read() line. All these variables are declared locally in
> the method doing the work, not at the class level, so there is no
> synchronization needed on them. This method is called from the doPost()
> method of the servlet class.
>
> Here are a few code lines for context setting:
>
> req is my HttpServletRequest
> iStream is a ServletInputStream
>
>
> Then I have:
>
> len = req.getContentLength();
> b = new byte[ len ];
> iStream = req.getInputStream();
> /* this is the line 198 that the above thread dump is waiting for: */
> strLen = iStream.read( b, 0, len );
> iStream.close();
>
>
> And then I convert b to a string and finish processing. Is there
> anything stupid I'm missing that would cause the .read() to be slow? Or
> is it just that my OS tcp/ip stack and/or network infrastructure appear
> to be slow? I did quite a bit of reading on InputStream performance, it
> couldn't find any suggestions to improve on what I've already got (the
> biggest one was to read the whole thing at once rather than
> byte-by-byte, and I'm already doing that).
socketRead0() most likely is really waiting for data to arrive. So now
that you have an indication your performance is restricted by network,
go ahead, install Wireshark and sniff a little traffic to verify, that
your clients are really slow in sending the data (or invalidate that
theory).
Caution: you should do a couple of thread dumps and verify, that the
code is waiting in socketRead0() in nearly all cases. Of course it's
always possible that it is pure coincidence in a single dump.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Peformance on socket reads
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David kerber [mailto:dckerber@verizon.net]
> Subject: Re: Peformance on socket reads
> What method would you suggest? Create the byte array long enough to
> handle any possible input and then read without specifying the length?
No, keep allocating the byte array based on the content-length (plus perhaps a bit more for insurance); but if you discover that there is more input than that, get a larger one and do System.arraycopy() to save what you already processed. That shouldn't happen very often, so it's not a performance issue. If it does happen often, your clients are broken and need to be fixed.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Performance on socket reads
Posted by Bill Barker <wb...@wilshire.com>.
"David kerber" <dc...@verizon.net> wrote in message
news:4A0DBF88.6030208@verizon.net...
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David,
>>
>> On 5/15/2009 12:22 PM, David kerber wrote:
>>
>>> But the code works; it just seems to be a little slow.
>>>
>>
>> Gotcha. How slow are we talking, here? I'm not sure whether the
>> underlying InputStream, here, is buffering, but you could try:
>>
> Not noticeably slow from a human watching it viewpoint, but when I do a
> thread dump, I see quite a few of the threads waiting on the .read()
> statement. "quite a few" in the case of the one I did just now (the
> busiest time of day for this app) means 12 out of the total of 75
> http-processorXXX threads.
>
>> iStream = new BufferedInputStream(req.getInputStream());
>>
>> ... to see if that improves things at all.
>>
> I was wondering about that, too. I couldn't see anything that
> specifically said whether the InputStream from an HttpServletRequest was
> buffered or not, but the implication from some reading about a 3rd party
> BufferedServletInputStream is that TC 4.x and later provide a buffer for
> it.
>
Yes, the TC implementation of the ImputStream from the Request is buffered
(although it doesn't extend BufferedInputStream). It is possible that
wrapping it in a BufferedInputStream could even slow the app down (by making
it wait until all the data is available).
>>
>>> At this point, [the data is] still encrypted, and a string may not
>>> properly
>>> handle some of the bytes.
>>>
>>
>> Oh, right. I forgot you were sending encrypted data.
>>
>>
>>>> I think you may have better luck reading until there is no more input,
>>>>
>>> What method would you suggest? Create the byte array long enough to
>>> handle any possible input and then read without specifying the length?
>>>
>>
>> Something like that. After thinking a bit about it, specifying more
>> bytes to read than are available either blocks (waiting for more data
>> that will come) or returns after reading fewer bytes (because the stream
>> is closed and there's no more to read). Your code should be pretty good
>> as-is.
>>
>
> Thanks,
> D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Performance on socket reads
Posted by David kerber <dc...@verizon.net>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David,
>
> On 5/15/2009 12:22 PM, David kerber wrote:
>
>> But the code works; it just seems to be a little slow.
>>
>
> Gotcha. How slow are we talking, here? I'm not sure whether the
> underlying InputStream, here, is buffering, but you could try:
>
Not noticeably slow from a human watching it viewpoint, but when I do a
thread dump, I see quite a few of the threads waiting on the .read()
statement. "quite a few" in the case of the one I did just now (the
busiest time of day for this app) means 12 out of the total of 75
http-processorXXX threads.
> iStream = new BufferedInputStream(req.getInputStream());
>
> ... to see if that improves things at all.
>
I was wondering about that, too. I couldn't see anything that
specifically said whether the InputStream from an HttpServletRequest was
buffered or not, but the implication from some reading about a 3rd party
BufferedServletInputStream is that TC 4.x and later provide a buffer for it.
>
>> At this point, [the data is] still encrypted, and a string may not properly
>> handle some of the bytes.
>>
>
> Oh, right. I forgot you were sending encrypted data.
>
>
>>> I think you may have better luck reading until there is no more input,
>>>
>> What method would you suggest? Create the byte array long enough to
>> handle any possible input and then read without specifying the length?
>>
>
> Something like that. After thinking a bit about it, specifying more
> bytes to read than are available either blocks (waiting for more data
> that will come) or returns after reading fewer bytes (because the stream
> is closed and there's no more to read). Your code should be pretty good
> as-is.
>
Thanks,
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Performance on socket reads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
On 5/15/2009 12:22 PM, David kerber wrote:
> But the code works; it just seems to be a little slow.
Gotcha. How slow are we talking, here? I'm not sure whether the
underlying InputStream, here, is buffering, but you could try:
iStream = new BufferedInputStream(req.getInputStream());
... to see if that improves things at all.
> At this point, [the data is] still encrypted, and a string may not properly
> handle some of the bytes.
Oh, right. I forgot you were sending encrypted data.
>> I think you may have better luck reading until there is no more input,
>
> What method would you suggest? Create the byte array long enough to
> handle any possible input and then read without specifying the length?
Something like that. After thinking a bit about it, specifying more
bytes to read than are available either blocks (waiting for more data
that will come) or returns after reading fewer bytes (because the stream
is closed and there's no more to read). Your code should be pretty good
as-is.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoNuYUACgkQ9CaO5/Lv0PAOwQCgxCEVgtRLYG0V1mFC421dC318
8wkAoLQ1WwoQULSMcTiyEFGHQaGYTBPL
=ADDW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
On 5/15/2009 2:28 PM, David kerber wrote:
>
> The content-type is application/binary.
I might have used "application/octet-stream", but it's really just
semantics.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoNuj0ACgkQ9CaO5/Lv0PAZXACgjkZJUayvnBK/16BXcgZC/nxp
TU4An3BXtBFI6A4RzioZH/MpZB/2vqiJ
=Gt6+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by David kerber <dc...@verizon.net>.
David kerber wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David,
>>
>> On 5/14/2009 8:34 AM, David kerber wrote:
>>
>>> len = req.getContentLength();
>>> b = new byte[ len ];
>>>
>>
>> Don't forget to check to see if getContentLength() returned zero.
>>
> I do, it's just not in that code snippet.
>> What is the content-type here? Is it application/x-www-form-urlencoded?
>> Are you calling req.getParameter() or any of the same family of
>> functions? If both of those are true, then Tomcat has already read the
>> body of the request, and you won't be able to re-read it.
>>
> I don't recall the content-type off the top of my head (and I don't
> have the source of the sending app at hand), and I don't use
> req.getParameter() at all. But the code works; it just seems to be a
> little slow.
The content-type is application/binary.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by David kerber <dc...@verizon.net>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David,
>
> On 5/14/2009 8:34 AM, David kerber wrote:
>
>> len = req.getContentLength();
>> b = new byte[ len ];
>>
>
> Don't forget to check to see if getContentLength() returned zero.
>
I do, it's just not in that code snippet.
> What is the content-type here? Is it application/x-www-form-urlencoded?
> Are you calling req.getParameter() or any of the same family of
> functions? If both of those are true, then Tomcat has already read the
> body of the request, and you won't be able to re-read it.
>
I don't recall the content-type off the top of my head (and I don't have
the source of the sending app at hand), and I don't use
req.getParameter() at all. But the code works; it just seems to be a
little slow.
>
>> iStream = req.getInputStream();
>> /* this is the line 198 that the above thread dump is waiting for: */
>> strLen = iStream.read( b, 0, len );
>> iStream.close();
>>
>
> If you want a String, why not use req.getReader() instead of
> req.getInputStream()?
>
At this point, it's still encrypted, and a string may not properly
handle some of the bytes. I don't make it a string until I'm done
decrypting it (forgot to mention that point in my original post).
> I think you may have better luck reading until there is no more input,
>
What method would you suggest? Create the byte array long enough to
handle any possible input and then read without specifying the length?
> rather than relying upon the Content-Length matching the available data
> (which really /should/ work, but obviously something else is happening
> here).
>
Thanks!
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Peformance on socket reads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
On 5/14/2009 8:34 AM, David kerber wrote:
> len = req.getContentLength();
> b = new byte[ len ];
Don't forget to check to see if getContentLength() returned zero.
What is the content-type here? Is it application/x-www-form-urlencoded?
Are you calling req.getParameter() or any of the same family of
functions? If both of those are true, then Tomcat has already read the
body of the request, and you won't be able to re-read it.
> iStream = req.getInputStream();
> /* this is the line 198 that the above thread dump is waiting for: */
> strLen = iStream.read( b, 0, len );
> iStream.close();
If you want a String, why not use req.getReader() instead of
req.getInputStream()?
I think you may have better luck reading until there is no more input,
rather than relying upon the Content-Length matching the available data
(which really /should/ work, but obviously something else is happening
here).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoNkvwACgkQ9CaO5/Lv0PC6LgCeKxfj76DEe3zvkp7xLAvyDd5b
WYEAoJLpw50J6iGdu2s0QPeL5Q+eoRB9
=uYLB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org