date:20200107

RE: performance issue with Tomcat 8.5.35 in org.apache.tomcat.util.net.NioBlockingSelector.write API

2020-01-07 Thread Rathore, Rajendra

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 
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 
Sent: Tuesday, January 7, 2020 4:11 PM
To: Tomcat Users List 
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  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

Re: [OT] Re: Maven Warning. Ubuntu Users

2020-01-07 Thread Zahid Rahman

  >A version of what?
 MAVEN
MAVEN
MAVEN

In light of this video https://youtu.be/idViw4anA6E
Of http.

You and your let's encrypt must be the longest troll on this line.

Take your wares and peddle them somewhere else carpet beggar.




On Wed, 8 Jan 2020, 01:12 Christopher Schultz, 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Zahid,
>
> On 1/6/20 3:13 PM, Zahid Rahman wrote:
> > That must be the reason why Apache Netbeans is using a version from
> >  2015
>
> A version of what?
>
> > and Apache Struts is recommending to use jdk 8.
> Apache Struts 2.5.x supports Java 7 and later. I see no official
> documentation recommending a specific Java version over any others.
>
> > Because there is somebody like you keeps telling people it is off
> > topic and Giant IT companies are not releasing jdk further than JDK
> > 8.
>
> Maybe just not for free.
>
> https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads
> - -5672538.html
> https://www.azul.com/category/java13/
>
> Admittedly, Oracle's JDK/JRE is based upon
> https://openjdk.java.net/projects/jdk/13/ so maybe that doesn't count
> as a separate release.
>
> But no, IBM doesn't appear to have a new version beyond Java 11.
>
> > The issue is a miserable and disgraceful failure in coordination by
> > Apache Foundation.
>
> So you found a problem with a package provided by Ubuntu/Debian, and
> your solution was to install the official Maven package from the
> Apache Software Foundation. And your conclusion is that the ASF is the
> miserable and disgraceful party, here?
>
> I'm so confused.
>
> It's worth pointing-out that there is no enforced coordination between
> ASF projects. Some of them work together in almost lock-step, like APR
> and httpd. Others are completely de-coupled. Some ignore each other
> (e.g. Apache Maven and Apache Tomcat). It's up to the individual
> projects to determine if/how they will work together.
>
> You may wish to read a little more about the ASF before you make
> blanket statements about it.
> https://community.apache.org/projectIndependence.html
>
> If you are dissatisfied with the ASF communities (or maybe just a few
> in particular), may I suggest that you take one of these two courses
> of action:
>
> 1. Volunteer to improve the situation. Usually in the form of
> patches/PRs to that project.
>
> 2. Take your complaints elsewhere.
>
> - -chris
>
> > On Mon, 6 Jan 2020, 19:45 Mark Thomas,  wrote:
> >
> >> On 06/01/2020 18:37, Zahid Rahman wrote:
> >>> To all ubuntu Maven  users.
> >>
> >> This is off-topic for this mailing list.
> >>
> >> Please keep posts on this list on topic.
> >>
> >> Thanks,
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Do NOT  install maven using sudo apt install maven
> >>>
> >>> Install by  direct download  only  from
> >>> https://maven.apache.org/download.cgi
> >>>
> >>> BECAUSE:
> >>>
> >>> "I seem to remember they [ubuntu] have their own build of Maven
> >>> which differs from the Apache source.
> >>>
> >>> ( https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1754602
> >>> suggests it's a known bug in their packaging/build? )
> >>>
> >>> If you download Maven from http://maven.apache.org/download.cgi
> >>> and
> >> follow
> >>> the instructions in http://maven.apache.org/install.html then
> >>> you
> >> shouldn't
> >>> see those warnings. " ‐---
> >>>
> >>> The Java 11 warning mentions that
> >>> "/usr/share/maven/lib/guice.jar" has a class named
> >>> "com.google.inject.internal.cglib.core.$ReflectUtils$1"
> >>>
> >>> This looks suspect because the official Maven distribution uses
> >>> the "no-AOP" version of Guice which doesn't contain any CGLIB
> >>> classes. It suggests that whoever provided that copy of Maven
> >>> has replaced the
> >> "no-AOP"
> >>> version with the "AOP" version, and this will cause warnings on
> >>> Java 11. (The "AOP" version uses CGLIB which currently relies
> >>> on certain
> >> reflective
> >>> access that Java 11 warns about - whereas the "no-AOP" version
> >>> doesn't.)
> >>>
> >>
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VLGgACgkQHPApP6U8
> pFjmuw//cXWmOfcRCt/2FqHwWZwuB23fIXrzEdOJ3RPdJEfwDUxtVcz/rXGI9TB6
> ae64Vr1+8Znh8xX+wGvoScITo3L/qUPWDkWf5W3rAhhQNWCqsvJvCM4Sw7YE4ytE
> pv9gT9seDOx+wiGq+FQ5gdy1T7adgTwgYAVLCeuG/bvk4niz9vtYxXBXdfeTIb5e
> fjYY7sRzyhC9TQy8wq35JGXtlabxgXOPYqtlSRaZGX4m3wiLjOCyN5O+zXtmYfFk
> pnQ9exU5fez4RHgMt2ys9WFXYH8ZHVqIEkCwaFMrufOKGI+P6PVhtuj3c1mnHa0H
> RjSXHnd+hnUhwO3TWN7ClDH50KOHJCoT6kfXPh/RYxBC6yoY71DsFtP+l27xkVaV
> xh5nGkMcbBBLEpifhGBFd2tmjpRCMZqDU2433ROJJx7bqpNrLuAzRYcb8DISclSE
> ylqWL+s46ws251dp9RNBXJ1IYCI4fSxw/jiQUtjk7JCM1d8K6EyXK3NYC8IMLl9P
> Vw9OJdOhPvWHYISe

Re: Dates on Linux vs. Windows - Resolved

2020-01-07 Thread Jerry Malcolm

First of all, a big thank you to everyone who responded to this one.  I 
doubt I'd have figured it out for days without your guidance and help.


And the winner is the JVM timezone.  But the problem was NOT that 
the JVM wasn't set to US Central time.  The problem was that it WAS set 
to US Central, apparently inherited from the Linux OS TZ.  There was no 
parameter on the tomcat java command that set the timezone.  So I added 
one and set it to America/Chicago.  No change.  But since it appeared we 
were already double-dipping and converting from GMT to central twice 
(i.e. subtracting an additional 6 hours), I figured ok tell the JVM 
to stay in GMT and not do any conversions.  So now, the database returns 
Central time dates and times, but JVM no longer thinks it needs to 
convert again to 'more central'.


This is about as convoluted and ugly as it gets.  And I don't make any 
claims of thinking I can give a rational explanation for why it works 
this way.  But it's on to fight a battle on another hill now.


Just to summarize for anybody who comes along with a similar problem 
I original set the timezone of mySQL RDS instance to Central time when I 
created it months back (unchangable after it's set).  I set my Linux 
timezone to Central as well in order to make my log files have entries 
with the correct timestamps.  But as I described earlier, changing the 
OS timezone made the JVM also go to Central as well.  But the JVM 
apparently assumed the database was in GMT so it subtracted 6 more hours 
off the already-central time from the db.  I guess the real error was 
not initially leaving the MySQL RDS in GMT.  But since that's not 
changeable without recreating a whole new RDS instance, the next option 
is what I did with the jvm.   Makes total sense, right???  :-)


Thanks again.

Jerry


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

Re: Breakthrough, Re: Let's Encrypt with Tomcat?

2020-01-07 Thread James H. H. Lampert


On 1/7/20 4:54 PM, Christopher Schultz wrote:


I have further confused you, because TCP packets+connections also have
state, and I misspoke.


Think nothing of it: at my age, I'm easily confused.

--
JHHL

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

Re: Dates on Linux vs. Windows

2020-01-07 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/7/20 7:42 PM, Jerry Malcolm wrote:
> Summarizing what I know now... when I use the command line on the
> linux instance and do a mysql query, I get the correct date (i.e.
> the date that I set, the date I wanted, the date that mySQL exports
> to SQL file, and the date that appears in Windows tomcat).  So this
> pretty much rules out the problem being in the mySQL server.  I
> would think this also rules out the problem being in some timezone
> setting  in the base Linux system hosting tomcat since I get the
> right date in the command line. That only leaves the JVM; JDBC
> package, and MySQL connector.

The JDBC package and the MySQL connector are the same thing. They will
convert correctly from the server's time zone into the JVM's time zone.

> MySQL RDS instance is set to US Central timezone.  So it's going to
> return dates in central time, right?

Sort of? See my other reply for ... details.

> It appears that jdbc and/or the connector is assuming the db is gmt
> and knocking off another 6 hours. Is there some place in the
> datasource to tell tomcat the timezone of the database so it knows
> not to convert TZ when it doesn't need to? I can't find anything
> like that in the datasource documentation.

Your JVM is probably in GMT/UTC.

The conversion is not the problem. It's just the output that is
causing you pain.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VMeoACgkQHPApP6U8
pFjzWRAAlSOt1Yu3jGYUzM0zxfuaSNJ88Tu0QS2Ibt3AtuJEqwvU6LWmjS+B1DpR
THxpP/RYEUbEoe9BMxm6aN4qT0DpmP5sWqbceqcOmLH1ACAGalvtX/mLh9auSXk/
+paOkUB6aZ6CNTXwth8O0c89KuKIdydw0jAcJesU32leuKzOsgPlY5Ey5QG/G6Gv
YvqY61730vQ573fTzAFX84w10v+Q7+vTGxzS5RgtQcjCK6vH6jXPinzmkTOKSa3E
7gC2yHGJ0yQvRUVNYWqUS8yiBX5GmrO7bXPGxIT5jbfzdlCOUgciElLaoO1WmxTX
1tU6wX5zh3Mm3ACNN6+JRPJXUkJNO5bcfkvVRUkNoyyFyEFMHqg9edDQLMDA3IlU
+KTzFLJqEsTvxiZ3t5T5b/POo8uNxleMO23AEzZZYVCTtl9pfPi9d/EtLsbwUhO2
USpLiKhEmiBe0EXFdnXJEBIkaMh7TllVZqeueTgfyMdWq42XIxb6xtfbZhRBjhYT
i8tBwOXlTdI6NltW7RA9ucPcCh6esNYRwPcozXlwVBr8yJPNAWtL3y0OCO5/kGTw
73BPCiNcFmm5bR9Qh+2CRrjIzYaEmoLDEccsScfSrLIvne4mrKgyi7FkFbH7tlKk
0IPxvJrwNBjtHLPppZdnqDYaXAQX+j+mAcSbJVU9dFhjv3tBWzM=
=3pbq
-END PGP SIGNATURE-

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

Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?

2020-01-07 Thread James H. H. Lampert

On 1/7/20 4:19 PM, Christopher Schultz wrote:

You probably "spelled" something incorrectly. It might be a
quoting/escaping issue. It might be a literal misspelling/typo.

The JMXProxyServlet shouldn't NPE like that, though.

I'll take a look and see if we can give you a better error message
than that when it happens.

Well given that (1) there's no production data at stake, (2) you don't
know where this server is, (3) the test user will be removed permanently
and replaced with something else once this problem is resolved, and (4)
the test user will never be active if I'm not running actual tests,
there's no reason to censor the curl call.

curl -k -u test:test
https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22&op=reloadSslHostConfigs

I tried it with or without quote marks around the URL; I tried it both
with the user in a "-u" clause, as above, or with the user prefixing the
domain. In all four cases, I get what appears to be the exact same
stacktrace as before.

I can't tell any difference, other than the user, and specifying a port,
between that and the "hard-coded" curl call on slide 35 of the
presentation. And if I leave out the port number, I get "connection
refused."

48 matches

Mail list logo