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, 2020 11:43 AM
To: 'Tomcat Users List' <users@tomcat.apache.org>
Subject: RE: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

Can someone please help me to find out the root cause for below issue.

Thanks and Regards,
Rajendra Rathore
9922701491

-----Original Message-----
From: Rathore, Rajendra
Sent: Tuesday, January 7, 2020 4:16 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: RE: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

Hi Remy,

Thanks for the reply,

As you mention below points

"There's a problem only if things are blocked improperly, for example if the 
client is correctly reading the data and/or there's no network backlog.
Also the timeout configured on the connector must be respected by the 
operation."

1. how can we check the network backlog or data read/write not working 
properly, if any tool pls let us know 2. how can we set connector timeout.

Thanks and Regards,
Rajendra Rathore
9922701491

-----Original Message-----
From: Rémy Maucherat <r...@apache.org>
Sent: Tuesday, January 7, 2020 4:11 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: performance issue with Tomcat 8.5.35 in 
org.apache.tomcat.util.net.NioBlockingSelector.write API

External email from: users-return-269207-rarathore=ptc....@tomcat.apache.org

On Tue, Jan 7, 2020 at 6:33 AM Rathore, Rajendra <rarath...@ptc.com> wrote:

> Hi Rémy/ Christopher,
>
> It will stuck there for 10-15 minutes, so it will take time to load 
> simple Web UI, there is no WebSocket call. I am giving you one of the 
> sample where it will take 90% time in write operation, sometime it will reach 
> to 100%.
>
>
>                                                          |    |
>
> O-org.apache.coyote.ajp.AjpProcessor.writeData(AjpProcessor.java:1331)
> count=1669(%92.877)
>                                                          |    |
>                       
> O-org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase
> .java:385)
> count=1669(%92.877)
>                                                          |    |
>                         
> O-org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWra
> pperBase.java:462)
> count=1669(%92.877)
>                                                          |    |
>                           
> O-org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBa
> se.java:726)
> count=1669(%92.877)
>                                                          |    |
>                             
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioE
> ndpoint.java:1316)
> count=1669(%92.877)
>                                                          |    |
>                               
> O-org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.jav
> a:157)
> count=1669(%92.877)
>                                                          |    |
>                                 
> O-org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSele
> ctor.java:114)
> count=1667(%92.766)
>                                                          |    |
>                                 |
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitWriteLa
> tch(NioEndpoint.java:1160)
> count=1667(%92.766)
>                                                          |    |
>                                 |    
> O-org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.awaitLatch(NioEndpoint.java:1157)
> count=1667(%92.766)
>                                                          |    |
>                                 |
> O-java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> count=1667(%92.766)
>
>
It's a normal blocking write, and the await does not consume CPU (it sits there 
however and a profiler will count that but it doesn't matter).
There's a problem only if things are blocked improperly, for example if the 
client is correctly reading the data and/or there's no network backlog.
Also the timeout configured on the connector must be respected by the operation.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to