r even the whole JVM) had
> > > terminated between the time you took the heap-dump and the thread dump.
> > > Most likely, the monitor was owned by another thread when you took your
> > > thread-dump. Try using other tools which *do* reveal the lock-holders
> > > id
t; This issue has happened a few times. "Busy Thread Count" was high
> during the problem period. JVM was up and running when I collected
> heap and thread dumps - pid was not changed in-between. I used jstack,
> visualvm, jcmd - nothing revealed owing thread details. Only heap
&g
times. "Busy Thread Count" was high
during the problem period. JVM was up and running when I collected
heap and thread dumps - pid was not changed in-between. I used jstack,
visualvm, jcmd - nothing revealed owing thread details. Only heap
dumps had some information on tha
()
method. So, if something bad happens to the thread which is trying to
establish a connection, then lock will be held without a proper owner
and a thread blocking situation will be created. Am I interpreting the
code correctly? Should we not handle any failure inside get()?
Also, I still have no
ed on singleConnectionLock.
That lock is getting released either in the close() or release()
method. So, if something bad happens to the thread which is trying to
establish a connection, then lock will be held without a proper owner
and a thread blocking situation will be created. Am I interpreting
Thank you Mark
Andrew
> On Oct 8, 2021, at 1:44 AM, Mark Thomas wrote:
>
> On 07/10/2021 22:23, Javateck wrote:
>> Hi Mark,
>> Just wondering whether we have a radar to track this, will it be in release
>> notes for next release?
>
> The fix is in 9.0.54 and is listed in the changelog.
>
>
On 07/10/2021 22:23, Javateck wrote:
Hi Mark,
Just wondering whether we have a radar to track this, will it be in release
notes for next release?
The fix is in 9.0.54 and is listed in the changelog.
Mark
Thanks,
Andrew
On Sep 27, 2021, at 8:54 AM, Mark Thomas wrote:
On 27/09/2021 15:
Hi Mark,
Just wondering whether we have a radar to track this, will it be in release
notes for next release?
Thanks,
Andrew
> On Sep 27, 2021, at 8:54 AM, Mark Thomas wrote:
>
> On 27/09/2021 15:55, Mark Thomas wrote:
>>> On 27/09/2021 09:08, Goldengate liu wrote:
>>> Hi Mark,
>>>
>>>I’
Mark,
Thank you very much for the quick fix
Andrew
> On Sep 27, 2021, at 8:54 AM, Mark Thomas wrote:
>
> On 27/09/2021 15:55, Mark Thomas wrote:
>>> On 27/09/2021 09:08, Goldengate liu wrote:
>>> Hi Mark,
>>>
>>>I’m uploading some test files
>> Thanks for the test case. I'm looking at th
On 27/09/2021 15:55, Mark Thomas wrote:
On 27/09/2021 09:08, Goldengate liu wrote:
Hi Mark,
I’m uploading some test files
Thanks for the test case. I'm looking at this now.
Bug found and fixed.
One thing to note is that with chunked encoding it is possible for you
to see isReady() retu
? this is a basic use case.
Thanks,
Andrew
On Sep 22, 2021, at 1:14 AM, Mark Thomas <mailto:ma...@apache.org>> wrote:
On 22/09/2021 08:22, Goldengate liu wrote:
Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to
read as non-blocking way as long as there is d
d to read as non-blocking way as long as there is data ready locally by calling isReady method and check the ready condition before calling read, and read should throw IllegalStateException if called by caller when data is not readyThe above only applies if the servlet is in async mode. Is it?correc
On 22/09/2021 08:22, Goldengate liu wrote:
Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to read as
non-blocking way as long as there is data ready locally by calling isReady
method and check the ready condition before calling read, and read should throw
>> Hi Chris,
>> Servlet 3.1 spec defines that ServletInputStream can be used to read as
>> non-blocking way as long as there is data ready locally by calling isReady
>> method and check the ready condition before calling read, and read should
>> throw IllegalStat
On 21/09/2021 23:01, Javateck wrote:
Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to read as
non-blocking way as long as there is data ready locally by calling
isReady method and check the ready condition before calling read, and
read should throw
Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to read as
non-blocking way as long as there is data ready locally by calling isReady
method and check the ready condition before calling read, and read should throw
IllegalStateException if called by caller when data is
(ServletInputStream.isReady()) {
ServletInputStream.read(buffer); // this becomes blocking
}
I tried with jetty, it’s working fine
When I did the test, I was holding the sending packet from client side
Not sure whether anyone has tried this
InputStream is always blocking.
Are you trying to use async
read call is blocked after isReady returns true
>
> if (ServletInputStream.isReady()) {
> ServletInputStream.read(buffer); // this becomes blocking
> }
>
> I tried with jetty, it’s working fine
>
> When I did the test, I was holding the sending packet from clien
(buffer); // this becomes blocking
}
I tried with jetty, it’s working fine
When I did the test, I was holding the sending packet from client side
Not sure whether anyone has tried this
Thanks,
Andrew
-
To unsubscribe, e-mail
Hi,
I have a question regarding async servlets and request recycling. In
particular, I'm interested in request recycling by tomcat when an IO
error occurs. In my use case, I'm using non-blocking reads with a
ReadListener but blocking writes (no WriteListener).
The main question can be
On 09/01/2020 04:49, Rathore, Rajendra wrote:
> Hi Team,
>
> If someone know how to check whether proper read/write operation done or not
> or it will caused by network please let me know because it is blocking for me.
I recommend you ignore the advice from Zahid.
The stack tra
o help me out to know the root cause of the
> problem?
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Zahid Rahman
> Sent: Thursday, January 9, 2020 10:53 AM
> To: Tomcat Users List
> Subject: Re: BLOCKIN
Rathore
> 9922701491
>
> -Original Message-
> From: Zahid Rahman
> Sent: Thursday, January 9, 2020 10:53 AM
> To: Tomcat Users List
> Subject: Re: BLOCKING: performance issue with Tomcat 8.5.35 in
> org.apache.tomcat.util.net.NioBlockingSelector.write API
>
> Extern
https://youtu.be/VhSu1pRIEqQ
This will you understand . Also explains io blocking performance.
On Thu, 9 Jan 2020, 05:25 Rathore, Rajendra, wrote:
> Hi Zahid,
>
> How below link is going to help me out to know the root cause of the
> problem?
>
> Thanks and Regards,
Hi Zahid,
How below link is going to help me out to know the root cause of the problem?
Thanks and Regards,
Rajendra Rathore
9922701491
-Original Message-
From: Zahid Rahman
Sent: Thursday, January 9, 2020 10:53 AM
To: Tomcat Users List
Subject: Re: BLOCKING: performance issue with
know because it is blocking
> for me.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Wednesday, January 8, 2020 11:43 AM
> To: 'Tomcat Users List'
&g
ll caused by network please let me know because it is blocking
> for me.
>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Rathore, Rajendra
> Sent: Wednesday, January 8, 2020 11:43 AM
> To: 'Tomcat Users List'
&g
Hi Team,
If someone know how to check whether proper read/write operation done or not or
it will caused by network please let me know because it is blocking for me.
Thanks and Regards,
Rajendra Rathore
9922701491
-Original Message-
From: Rathore, Rajendra
Sent: Wednesday, January 8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6/29/17 5:22 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Re: RemoteEndpoint.Async sendText blocking
>
>> When the BIO connector is in use, you end up with
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: RemoteEndpoint.Async sendText blocking
> When the BIO connector is in use, you end up with weird things like
> this. I would switch to BIO if you want to use async.
Might want to rephrase that... Pres
ssion of a text message. This method returns before
>>>> the message is transmitted." To me, this implies that the
>>>> method should return immediately regardless of network status
>>>> (i.e. it should still return immediately even if the socket
>>
a text message. This method returns before the message is
> > transmitted." To me, this implies that the method should return
> > immediately regardless of network status (i.e. it should still
> > return immediately even if the socket connection has died without
> > closi
the message is
> transmitted." To me, this implies that the method should return
> immediately regardless of network status (i.e. it should still
> return immediately even if the socket connection has died without
> closing), but I've observed it blocking on writes to a broken
>
ork status (i.e. it should still return immediately even if the socket
connection has died without closing), but I've observed it blocking on
writes to a broken connection.
I'm also dealing with a known issue with timeouts on Tomcat 7 with a BIO
connector (https://bz.apache.org/bugzilla/s
t; 2016 7:42 PM To: Tomcat Users List Subject: Re: Tomcat 6 | Tomcat
> with APR causing Thread Blocking
>
> Ravi,
>
> On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
>> HI Chris,
>
>> Sorry for a delayed response. Here is few information that you
>> asked for: 1.
I am able to crack this one.
Regards,
Ravi Ranjan
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, February 09, 2016 7:42 PM
To: Tomcat Users List
Subject: Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
-BEGIN PGP SIGNED
omcat 6.0.41 on Windows 7
> system with Java 7.
>
> As you said that if APR is not available the Java BIO (blocking
> I/O) connector will be used. For me this connector is working. I am
> still not able to pinpoint to exact difference between these two
> types of connectors, which m
HI Chris,
Sorry for a delayed response.
Here is few information that you asked for:
1. Tomcat Native Library version is 1.1.30 and APR version is 1.4.8
2. I am running my tomcat 6.0.41 on Windows 7 system with Java 7.
As you said that if APR is not available the Java BIO (blocking I/O
uot;
> SSLEngine="on" />
So far, so good. The only think you didn't mention was the versions of
APR and tcnative you were using, and your OS.
> I am using below connector, which i assume is a blocking type:
> connectionTimeout="2" redirectPort="844
Runtime<http://ivf.dlr.de/docs/apr.html>)Listener: (by configuring below
property in server.xml)
I am using below connector, which i assume is a blocking type:
In one of my webapp i am running a dll as a Java Process to validate some data.
This dll is accessed as a Process whene
Pentzlin,
On 10/29/15 8:41 AM, Mark Thomas wrote:
> On 29/10/2015 07:53, Pentzlin, David wrote:
>> Per default the protocol in server.xml is configured as protocol="HTTP/1.1".
>> with newer tomcat versions this will use a non blocking protocol if possible.
>>
>
On 29/10/2015 07:53, Pentzlin, David wrote:
> Per default the protocol in server.xml is configured as protocol="HTTP/1.1".
> with newer tomcat versions this will use a non blocking protocol if possible.
>
> Problem:
> Setup Tomcat (8.0.28) with default settings. Co
Per default the protocol in server.xml is configured as protocol="HTTP/1.1".
with newer tomcat versions this will use a non blocking protocol if possible.
Problem:
Setup Tomcat (8.0.28) with default settings. Copy a file in a webapp e.g.
webapps/root and download the file with limite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Omar,
On 8/10/14, 1:18 PM, Omar Belkhodja wrote:
> Finally, I almost understood the problem.
>
> The framework was generating a response without a Content-Length
> header. The AJP connector seems to be adding it as a
> Content-Length=0, although if
Finally, I almost understood the problem.
The framework was generating a response without a Content-Length header.
The AJP connector seems to be adding it as a Content-Length=0, although if
there are data.
So, currenly I have forced the framework to add the Content-Length header.
In fact, it is s
I have compared JSON logs (NOK) with XML logs (OK).
The main differences are here:
JSON
=
ajp_unmarshal_response::jk_ajp_common.c (688): Number of headers is = 6
ajp_unmarshal_response::jk_ajp_common.c (744): Header[0] [Pragma] =
[no-cache]
ajp_unmarshal_response::jk_ajp_common.c (744): He
Sorry, I forgot to answer to the second part of your e-mail.
Regarding Apache directives, I didn't add any specific directives. But, I'm
not the one that have configured all the server, so I'm not sure at 100%.
Regards,
Omar
2014-08-10 14:56 GMT+01:00 Rainer Jung :
> Am 10.08.2014 um 15:41 sch
Thanks for your answer Rainer. Please find attached the logs you requested.
Its is really strange, because it seems from the logs that jk_mod received
the answer...
Regards,
Omar
2014-08-10 14:56 GMT+01:00 Rainer Jung :
> Am 10.08.2014 um 15:41 schrieb Omar Belkhodja:
>
> Hi,
>>
>> I'm adding
Am 10.08.2014 um 15:41 schrieb Omar Belkhodja:
Hi,
I'm adding HTTPS access to my Java site. For that, I have chosen to leave
the management of HTTPS to an Apache server. The Apache server is
connecting to tomcat through mod_jk and AJP 1.3.
I'm logging all my Tomcat request/responses, and I'm fa
Hi,
I'm adding HTTPS access to my Java site. For that, I have chosen to leave
the management of HTTPS to an Apache server. The Apache server is
connecting to tomcat through mod_jk and AJP 1.3.
I'm logging all my Tomcat request/responses, and I'm facing the following
problem:
- If I access my URL
On Dec 29, 2013, at 11:45 AM, David Bullock
wrote:
> Well, the states of those threads look normal enough. Definitely not
> a resource starvation issue (which is what it 'feels' like). I guess
> some values are getting lost somewhere.
>
> Just looking at the stacktrace for the onWritePossible
Well, the states of those threads look normal enough. Definitely not
a resource starvation issue (which is what it 'feels' like). I guess
some values are getting lost somewhere.
Just looking at the stacktrace for the onWritePossible() example
though ... I'm not able to trace the same execution p
On Dec 23, 2013, at 7:55 PM, David Bullock
wrote:
> On 24 December 2013 07:58, Daniel Mikusa wrote:
>> On Dec 19, 2013, at 8:08 PM, David Bullock
>> wrote:
>>
>>> On 20 December 2013 04:10, Daniel Mikusa wrote:
>
>> Unfortunately, once this problem starts to occur onWritePossible doesn't g
On 24 December 2013 07:58, Daniel Mikusa wrote:
> On Dec 19, 2013, at 8:08 PM, David Bullock
> wrote:
>
>> On 20 December 2013 04:10, Daniel Mikusa wrote:
> Unfortunately, once this problem starts to occur onWritePossible doesn't get
> called back.
> When I take a thread dump of the code, it
tream();
>
>> Any thoughts on what's happening here?
>
> This is a total guess ... getOutputStream() is waiting on a lock it
> will never acquire?
No, it's non-blocking IO so it wouldn't (definitely shouldn't) wait here.
Instead it writes until i
On 20 December 2013 04:10, Daniel Mikusa wrote:
> When run, you'll see that it processes some of the requests but fails due to
> a timeout. I've not been able to replicate the other exceptions with the
> unit test though, so those may be unrelated.
> @WebServlet(asyncSupported = true)
>
I have a simple servlet which I'm running on Tomcat 8 trunk with Java 7. It's
using a non-blocking IO WriteListener to write 8k blocks of static data to the
response. The number of blocks it will write is given as a request parameter.
When I start out making individual requests to
er 27, 2013 1:48 PM
>>> To: Tomcat Users List
>>> Subject: Re: Another Non-blocking IO Question
>>>
>>> I'm seeing another issue with the same basic test though. After I tested
>>> the
>>> previous changes and confirmed they worked
On Nov 27, 2013, at 11:18 AM, Konstantin Preißer wrote:
> Hi Dan,
>
>> -Original Message-
>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
>> Sent: Wednesday, November 27, 2013 1:48 PM
>> To: Tomcat Users List
>> Subject: Re: Another Non-bl
> -Original Message-
> From: Konstantin Preißer [mailto:kpreis...@apache.org]
> Sent: Wednesday, November 27, 2013 5:18 PM
> To: 'Tomcat Users List'
> Subject: RE: Another Non-blocking IO Question
> 2) If I read correctly, when onAllDataRead() is called, you
Hi Dan,
> -Original Message-
> From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
> Sent: Wednesday, November 27, 2013 1:48 PM
> To: Tomcat Users List
> Subject: Re: Another Non-blocking IO Question
>
> I'm seeing another issue with the same basic test t
ote:
>>>>> On 25/11/2013 17:39, Daniel Mikusa wrote:
>>>>>> On Nov 25, 2013, at 12:19 PM, "Caldarale, Charles R"
>>>>>> wrote:
>>>>>>
>>>>>>>> From: Daniel Mikusa [mailto:dmik...@gopivotal.co
;>>> On Nov 25, 2013, at 12:19 PM, "Caldarale, Charles R"
>>>>> wrote:
>>>>>
>>>>>>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject:
>>>>>>> Another Non-blocking IO Question
>>>>>>
uot;
>>>> wrote:
>>>>
>>>>>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject:
>>>>>> Another Non-blocking IO Question
>>>>>
>>>>>> Most of the time it works, but in one case I'm seeing request
usa [mailto:dmik...@gopivotal.com] Subject:
>>>>> Another Non-blocking IO Question
>>>>
>>>>> Most of the time it works, but in one case I'm seeing requests
>>>>> hang.
>>>>
>>>> You know the ritual:
>>>>
On 26/11/2013 10:46, Mark Thomas wrote:
> On 25/11/2013 17:39, Daniel Mikusa wrote:
>> On Nov 25, 2013, at 12:19 PM, "Caldarale, Charles R"
>> wrote:
>>
>>>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject:
>>>> Another Non-block
On 25/11/2013 17:39, Daniel Mikusa wrote:
> On Nov 25, 2013, at 12:19 PM, "Caldarale, Charles R"
> wrote:
>
>>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject:
>>> Another Non-blocking IO Question
>>
>>> Most of the time it
On Nov 25, 2013, at 12:19 PM, "Caldarale, Charles R"
wrote:
>> From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
>> Subject: Another Non-blocking IO Question
>
>> Most of the time it works, but in one case I'm seeing requests hang.
>
> You know th
> From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
> Subject: Another Non-blocking IO Question
> Most of the time it works, but in one case I'm seeing requests hang.
You know the ritual:
1) Tomcat version?
2) JDK version?
3) Thread dump?
> in this case "onW
I've created a class that implements ReadListener and WriteListener, called
EchoListener. It's supposed to echo input to the output stream using the
non-blocking IO api. Most of the time it works, but in one case I'm seeing
requests hang.
I've debugged this a bit and her
I have a question on usage with non-blocking IO. I'm setting up a ReadListener
which implements onDataAvailable like this...
@Override
public void onDataAvailable() throws IOException
{
while (input.is
On Aug 16, 2013, at 12:32 PM, Mark Thomas wrote:
> On 16/08/2013 17:08, Daniel Mikusa wrote:
>> I have a simple echo servlet which uses the Servlet 3.1 Non-Blocking IO API.
>> It creates a ReadListener, that reads the request's input, buffers it,
>> creates a Wr
On 16/08/2013 17:08, Daniel Mikusa wrote:
> I have a simple echo servlet which uses the Servlet 3.1 Non-Blocking IO API.
> It creates a ReadListener, that reads the request's input, buffers it,
> creates a WriteListener that takes the buffered input and echoes it back to
I have a simple echo servlet which uses the Servlet 3.1 Non-Blocking IO API.
It creates a ReadListener, that reads the request's input, buffers it, creates
a WriteListener that takes the buffered input and echoes it back to the
response.
Most of the time this works OK, but when I s
On Aug 7, 2013, at 1:36 PM, Mark Thomas wrote:
> On 07/08/2013 17:14, Daniel Mikusa wrote:
>> I have a questions regarding the Non Blocking API introduced in Tomcat 8.
>>
>> I'm looking at the TestNonBlockingAPI test as an example, specifically the
>> NBReadS
On 07/08/2013 17:14, Daniel Mikusa wrote:
> I have a questions regarding the Non Blocking API introduced in Tomcat 8.
>
> I'm looking at the TestNonBlockingAPI test as an example, specifically the
> NBReadServlet class.
>
> @WebServlet(asyncSupported = true)
> public c
I have a questions regarding the Non Blocking API introduced in Tomcat 8.
I'm looking at the TestNonBlockingAPI test as an example, specifically the
NBReadServlet class.
@WebServlet(asyncSupported = true)
public class NBReadServlet extends TesterServlet {
private static final
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Baron,
On 11/18/12 9:00 PM, Baron Von Awsm wrote:
> I posted my issue at
>
> http://stackoverflow.com/questions/13446483/tomcat-servlet-response-blocking-problems-with-flush
>
> then discovered this mailing list.
>
> In the p
Finckler wrote:
Hello,
as far I understood, the websocket implementation of tomcat is
using one
thread per client.
Is there also a possibility to configure it to use non blocking IO?
No. That has not yet been implemented. It shouldn't be too hard
provided
that non-blocking is used be
t;> Hello,
>>>>> as far I understood, the websocket implementation of tomcat is
>>>>> using one
>>>>> thread per client.
>>>>> Is there also a possibility to configure it to use non blocking IO?
>>>> No. That has not yet been i
possibility to configure it to use non blocking IO?
No. That has not yet been implemented. It shouldn't be too hard provided
that non-blocking is used between messages and blocking is used during
messages. Obviously, the BIO connector will always use blocking.
Whoops. My bad. I implemented
client.
>>> Is there also a possibility to configure it to use non blocking IO?
>> No. That has not yet been implemented. It shouldn't be too hard provided
>> that non-blocking is used between messages and blocking is used during
>> messages. Obviously, the BIO connector
You can achieve that right now. Use the NIO connector, And then set up the
write buffer:
-Original Message-
> From: Christian Finckler [mailto:christian.finck...@gmx.de]
> Sent: Thursday, May 31, 2012 11:45 AM
> To: Tomcat Users List
> Subject: Re: non blocking Websockets?
&
Am 31.05.2012 11:09, schrieb Mark Thomas:
On 31/05/2012 10:02, Christian Finckler wrote:
Hello,
as far I understood, the websocket implementation of tomcat is using one
thread per client.
Is there also a possibility to configure it to use non blocking IO?
No. That has not yet been
On 31/05/2012 10:02, Christian Finckler wrote:
> Hello,
> as far I understood, the websocket implementation of tomcat is using one
> thread per client.
> Is there also a possibility to configure it to use non blocking IO?
No. That has not yet been implemented. It shouldn't be
Hello,
as far I understood, the websocket implementation of tomcat is using one
thread per client.
Is there also a possibility to configure it to use non blocking IO?
Then it should be easier to serve lots of connections without creating
unlimited threads.
Thank you,
Chris
On 28/12/2011 22:27, S Ahmed wrote:
> While benchmarking, I want to know if/when tomcat requires more threads
> (maxThreads).
>
> How can I figure this out?
Look in the logs. Tomcat reports the first time (and only the first
time) it hits maxThreads.
Mark
---
While benchmarking, I want to know if/when tomcat requires more threads
(maxThreads).
How can I figure this out?
i.e. I start benchmarking tomcat to see how it reacts to a high-traffic
spike, I want to make sure that tomcat isn't hitting the maxThreads when my
server has the ability resource wise
That's very illuminating, thanks.
I was looking at the table at the bottom of
http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#NIO_specific_configuration,
and got the impression APR was blocking also, but now I see 'waiting for
next request' is non-blocking in the TC7 ta
Matthew Tyson wrote:
>I guess what I'm asking is if I just start using the Servlet 3.0
>support
>for suspending requests out of the box, will it be a thread blocking
>implementation I'm using?
That depends what you mean by "thread blocking". Once startAsync has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew,
On 11/8/11 4:43 PM, Matthew Tyson wrote:
> So if I want to use Servlet 3.0 async (eg, a call to
> request.startAsync), and have it be handled without blocking IO, I
> need to use the NIO connector?
To repeat Mark's reply:
&
I guess what I'm asking is if I just start using the Servlet 3.0 support
for suspending requests out of the box, will it be a thread blocking
implementation I'm using?
HTTP APR/native is blocking as well, correct?
So if I want to use Servlet 3.0 async (eg, a call to request.startAsync)
On 08/11/2011 20:15, Matthew Tyson wrote:
> Hey Guys,
>
> It has been my assumption that Tomcat 7's comet implementation (ie,
> asyncSupported=true), will automatically use NIO processing.
Comet != Servlet 3.0 async
> Is that not true?
Yes, that is not true.
> Do I need to set the connector t
Hey Guys,
It has been my assumption that Tomcat 7's comet implementation (ie,
asyncSupported=true), will automatically use NIO processing.
Is that not true? Do I need to set the connector to be
org.apache.coyote.http11.Http11NioProtocol explicitly?
Thanks,
Matt
> From: AD [mailto:straightfl...@gmail.com]
> Subject: Blocking
>
> For example in Main Thread
> Name: main
> State: RUNNABLE
> Total blocked: 54 Total waited: 9
Once initialization is complete, the main thread does nothing but listen for
the shutdown command. The blocks a
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Subject: RE: Blocking
>
> yes I would be concerned about the 9 wait threads
It's not the number of waiting threads, it's the number of times this
particular thread has done a wait() call. Since the main thread i
does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Mon, 15 Dec 2008 22:53:52 -0500
> From: straightfl...@gmail.com
> To: users@tomcat.apache.org
> Subject: Blocking
>
Server has been up for about 5 hours under almost zero load but I am
concerned about some of the thread info in JConsole.. For example in Main
Thread
Name: main
State: RUNNABLE
Total blocked: 54 Total waited: 9
Does this indicate signifigant blocking? Maybe 10-15 requests total in the
last 5
- Original Message -
From: "Darren Kukulka" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, September 24, 2008 9:37 AM
Subject: Tomcat thread blocking
Hi,
I've recently observed a scenario in Tomcat 6.0.13 64-bit under SUN JDK
1.6_03 (x64 Windows platform), wh
Darren Kukulka wrote:
> Hi,
>
> I've recently observed a scenario in Tomcat 6.0.13 64-bit under SUN JDK
> 1.6_03 (x64 Windows platform), where a large number of threads show a
> status of BLOCKED.
>
> Can someone please advise the easiest and most effective way of helping
> identify the original
1 - 100 of 127 matches
Mail list logo
