RE: Client Cert TLS issue
Thanks Mark,
I was going to try to build tcnative with debug this weekend to try to help out
but life begged to disagree...i will try to step in that code next week as
well...
Appreciate it!
George
-Original Message-
From: Mark Thomas
Sent: Sunday, October 20, 2019 2:38 PM
To: users@tomcat.apache.org
Subject: Re: Client Cert TLS issue
Just a note to say I haven't forgotten this. I hope to look at this this week
unless someone beats me to it.
Mark
On 16/10/2019 17:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47 (windows x64,
>> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple
>> client tries to connect to the server, the server hangs on SSL handshake
>> until either the client times out on read or the server times out (if I set
>> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
>> have enabled the client side SSL trace and everything goes well until ECDH
>> key exchange (for brevity I have enabled only one TLS suite
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
>> requested. The cacerts we use is whatever comes with Azul's Java distro
>> which has ~150 entries + the custom cert for testing. The issue comes from
>> how the connector deals with trusted certs because if I reduce the cacerts
>> to contain only the test certificate, the request is being served without an
>> issue. Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
>
>
> This sounds like it is repeatable and that you have a system you can test
> with. On that basis here are a few things to try:
>
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake
> is hanging.
>
> 2. Try a binary search to try and determine if the issue is the number of
> certificates in the trust store or is caused by a specific certificate.
>
> It sounds like there might be an issue converting one or more of the trusted
> certs in the trust store to a format OpenSSL can work with.
>
>
>
> So the thread dumps didn't prove to be very useful - at least I couldn't see
> anything. I attached one of them (dump3.txt). But the trial and error in the
> binary searched proved it is not any certificate but a magic number of
> certificates in cacerts - 125 hang and 124 work. I don't know if it is a
> memory issue or buffer size issue - I tried removing and adding random certs
> around the 124/125 boundary and which one is out and in doesn't make a
> difference. I realize that a cert is rather large blob so it still could be
> memory issue with the size of the cert doesn't matter that much. In
> 8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
> tms, sr) we pass the DER-encoded certs to OpenSSL:
>
> // Pass along the DER encoded certificates of the accepted
> client
> // certificate issuers, so that their subjects can be
> presented
> // by the server during the handshake to allow the client
> choosing
> // an acceptable certificate
> for (X509Certificate caCert :
> x509TrustManager.getAcceptedIssuers()) {
> SSLContext.addClientCACertificateRaw(ctx,
> caCert.getEncoded());
> if (log.isDebugEnabled())
> log.debug(sm.getString("openssl.addedClientCaCert",
> caCert.toString()));
> }
>
> And this is not where it hangs. I stepped through the code through the
> handshaker but still haven't been able to figure out the hang point as I am
> not familiar with the details of that portion of TC code . I've attached two
> cacerts that you can plug in as truststore to try out the issue.
>
> George
>
>
>
>>
>> George
>>
>> [1]
>>
>> > port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
>> maxThreads="150" acceptCount="100" enableLookups="false"
>> disableUploadTimeout="true"
>> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
>> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> keystoreType="JKS"
>> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
>> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
>> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>> TLS_CHACHA20_POLY1305_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>>
Re: Client Cert TLS issue
Just a note to say I haven't forgotten this. I hope to look at this this
week unless someone beats me to it.
Mark
On 16/10/2019 17:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47 (windows x64,
>> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple
>> client tries to connect to the server, the server hangs on SSL handshake
>> until either the client times out on read or the server times out (if I set
>> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I
>> have enabled the client side SSL trace and everything goes well until ECDH
>> key exchange (for brevity I have enabled only one TLS suite
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if
>> requested. The cacerts we use is whatever comes with Azul's Java distro
>> which has ~150 entries + the custom cert for testing. The issue comes from
>> how the connector deals with trusted certs because if I reduce the cacerts
>> to contain only the test certificate, the request is being served without an
>> issue. Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
>
>
> This sounds like it is repeatable and that you have a system you can test
> with. On that basis here are a few things to try:
>
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake
> is hanging.
>
> 2. Try a binary search to try and determine if the issue is the number of
> certificates in the trust store or is caused by a specific certificate.
>
> It sounds like there might be an issue converting one or more of the trusted
> certs in the trust store to a format OpenSSL can work with.
>
>
>
> So the thread dumps didn't prove to be very useful - at least I couldn't see
> anything. I attached one of them (dump3.txt). But the trial and error in the
> binary searched proved it is not any certificate but a magic number of
> certificates in cacerts - 125 hang and 124 work. I don't know if it is a
> memory issue or buffer size issue - I tried removing and adding random certs
> around the 124/125 boundary and which one is out and in doesn't make a
> difference. I realize that a cert is rather large blob so it still could be
> memory issue with the size of the cert doesn't matter that much. In
> 8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
> tms, sr) we pass the DER-encoded certs to OpenSSL:
>
> // Pass along the DER encoded certificates of the accepted
> client
> // certificate issuers, so that their subjects can be
> presented
> // by the server during the handshake to allow the client
> choosing
> // an acceptable certificate
> for (X509Certificate caCert :
> x509TrustManager.getAcceptedIssuers()) {
> SSLContext.addClientCACertificateRaw(ctx,
> caCert.getEncoded());
> if (log.isDebugEnabled())
> log.debug(sm.getString("openssl.addedClientCaCert",
> caCert.toString()));
> }
>
> And this is not where it hangs. I stepped through the code through the
> handshaker but still haven't been able to figure out the hang point as I am
> not familiar with the details of that portion of TC code . I've attached two
> cacerts that you can plug in as truststore to try out the issue.
>
> George
>
>
>
>>
>> George
>>
>> [1]
>>
>> > port="8443" SSLEnabled="true" maxHttpHeaderSize="8192"
>> maxThreads="150" acceptCount="100" enableLookups="false"
>> disableUploadTimeout="true"
>> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS"
>> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> keystoreType="JKS"
>> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit"
>> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
>> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
>> TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
>> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
>>
Re: [OT] Re: Question about DirResourceSet?
> Mark,
>
> On 10/16/19 04:41, Mark Thomas wrote:
>>> On 10/15/19 09:37, Mark Thomas wrote:
>>> Isn't there a magic ${property} that can be used to mean "the
>>> context's root" so you don't have to use ${catalina.base}
>>> instead? I browsed through the document a bit and didn't find
>>> anything, but I could swear it's been discussed in the past.
>
>> There has been some discussion about exposing the context name via
>> additional routes but I don't remember anything specific about the
>> context root - apart from various discussions around getRealPath()
>> and not being able to assume that any web app maps to a location on
>> a file system.
>
> Right, getRealPath is the badness.
>
> But! Since all resource loading in Tomcat now goes through the
> resources framework, perhaps "${context-root}" could use a proper
> protocol that isn't "file:///" and point to the right place?
Well, the server.xml parsing should accept URLs anywhere you can specify
a file (assuming we've hooked up everything correctly) so you could
probably have ${context-root} return the result of
WebResourceRoot.getResource("/").getURL()
However...
That is only going to work *after* the web application has started but
you need it *before* the app starts to use it in context.xml.
I think this might end up being one of those cases where using
${catalina.base} is the better approach.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IOException: Broken Pipe causes "Calling [asyncError()] is not valid for a request with Async state [MUST_DISPATCH]" to be logged
On 20/10/2019 21:15, Johannes Edmeier wrote: > Am So., 20. Okt. 2019 um 16:11 Uhr schrieb Mark Thomas : >> >> On October 20, 2019 9:43:00 AM UTC, Johannes Edmeier >> wrote: >>> Hi folks, >>> >>> I have a async response which is designed to run as long as the >>> browser is connected (using SSE). >>> After the browser disconnects and data is written to the response >>> internally a "IOException: Broken Pipe" is thrown, which itself is not >>> logged, but there is some error from the state handling logged (see >>> below) which is quite noisy. Is there somehow to prevent this from >>> happening? or is this a bug? >> >> It may be an application bug or a Tomcat bug. The Tomcat side of things has >> been cleaned up for 9.9.28. >> >> Mark >> > > Thanks for your quick response. I did test it with the 9.0.28-dev and > indeed the error isn't logged anymore. > Thanks a lot and keep up the good work! Thanks for the feedback. It is worth pointing out (as this thread seems as relevant as any) that as soon as you see an I/O error on an async thread the expectation is that: - the async thread exists immediately (well, doesn't attempt to read from the request, write to the response, call complete() etc.) - Tomcat will call the onError() method of any attached AsyncListeners - One of those listeners will call complete() or dispatch() - If there is no call to complete() or dispatch(), Tomcat will call complete() It is that first step that usually where things start to go wrong. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IOException: Broken Pipe causes "Calling [asyncError()] is not valid for a request with Async state [MUST_DISPATCH]" to be logged
Am So., 20. Okt. 2019 um 16:11 Uhr schrieb Mark Thomas : > > On October 20, 2019 9:43:00 AM UTC, Johannes Edmeier > wrote: > >Hi folks, > > > >I have a async response which is designed to run as long as the > >browser is connected (using SSE). > >After the browser disconnects and data is written to the response > >internally a "IOException: Broken Pipe" is thrown, which itself is not > >logged, but there is some error from the state handling logged (see > >below) which is quite noisy. Is there somehow to prevent this from > >happening? or is this a bug? > > It may be an application bug or a Tomcat bug. The Tomcat side of things has > been cleaned up for 9.9.28. > > Mark > Thanks for your quick response. I did test it with the 9.0.28-dev and indeed the error isn't logged anymore. Thanks a lot and keep up the good work! Johannes > > > > >(also happens with tomcat 9.0.27) > >The spring boot guys also did have a lookt at it: > >https://github.com/spring-projects/spring-boot/issues/15057 > > > >Cheerio > >Johannes > > > > 2018-11-02 11:43:33.016 ERROR 17152 --- [nio-8080-exec-2] > >o.a.catalina.connector.CoyoteAdapter : Exception while processing > >an asynchronous request > > > >java.lang.IllegalStateException: Calling [asyncError()] is not valid > >for a request with Async state [MUST_DISPATCH] > >at > >org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:440) > >~[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:494) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at org.apache.coyote.Request.action(Request.java:430) > >~[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:382) > >~[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:239) > >~[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:241) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at > >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > >[na:1.8.0_181] > >at > >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > >[na:1.8.0_181] > >at > >org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > >[tomcat-embed-core-9.0.12.jar:9.0.12] > >at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] > >``` > > > >- > >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IOException: Broken Pipe causes "Calling [asyncError()] is not valid for a request with Async state [MUST_DISPATCH]" to be logged
On October 20, 2019 9:43:00 AM UTC, Johannes Edmeier wrote: >Hi folks, > >I have a async response which is designed to run as long as the >browser is connected (using SSE). >After the browser disconnects and data is written to the response >internally a "IOException: Broken Pipe" is thrown, which itself is not >logged, but there is some error from the state handling logged (see >below) which is quite noisy. Is there somehow to prevent this from >happening? or is this a bug? It may be an application bug or a Tomcat bug. The Tomcat side of things has been cleaned up for 9.9.28. Mark > >(also happens with tomcat 9.0.27) >The spring boot guys also did have a lookt at it: >https://github.com/spring-projects/spring-boot/issues/15057 > >Cheerio >Johannes > > 2018-11-02 11:43:33.016 ERROR 17152 --- [nio-8080-exec-2] >o.a.catalina.connector.CoyoteAdapter : Exception while processing >an asynchronous request > >java.lang.IllegalStateException: Calling [asyncError()] is not valid >for a request with Async state [MUST_DISPATCH] >at >org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:440) >~[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:494) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at org.apache.coyote.Request.action(Request.java:430) >~[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:382) >~[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:239) >~[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:241) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at >org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >[na:1.8.0_181] >at >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >[na:1.8.0_181] >at >org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >[tomcat-embed-core-9.0.12.jar:9.0.12] >at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] >``` > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot add dependency job for unit systemd-console-setup.service
On 10/20/19 3:28 PM, Emefile Francis Nwajie wrote: Thank you Andre for helping out. I figured that the "systemd-console-setup.service" was disabled in the server. I have enable it. However, tomcat still refuses to start. Below is the content of tomcat.service: [Unit] Description=Apache Tomcat 9 After=syslog.target network.target [Service] User=tomcat Group=tomcat Type=forking Environment=CATALINA_PID=/opt/tomcat/tomcat.pid Environment=CATALINA_HOME=/opt/tomcat Environment=CATALINA_BASE=/opt/tomcat ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh Restart=on-failure [Install] WantedBy=multi-user.target Now it doesn't give any error other than "Unit tomcat.service entered failed state." Tomcat logs its state in logfiles located in /var/log or /opt/tomcat/log. Maybe check those loggings to get an idea of why it fails to startup. ~Harm-Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot add dependency job for unit systemd-console-setup.service
Thank you Andre for helping out. I figured that the "systemd-console-setup.service" was disabled in the server. I have enable it. However, tomcat still refuses to start. Below is the content of tomcat.service: [Unit] Description=Apache Tomcat 9 After=syslog.target network.target [Service] User=tomcat Group=tomcat Type=forking Environment=CATALINA_PID=/opt/tomcat/tomcat.pid Environment=CATALINA_HOME=/opt/tomcat Environment=CATALINA_BASE=/opt/tomcat ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh Restart=on-failure [Install] WantedBy=multi-user.target Now it doesn't give any error other than "Unit tomcat.service entered failed state." On Sun, Oct 20, 2019 at 1:04 PM André Warnier (tomcat) wrote: > On 20.10.2019 10:07, Emefile Francis Nwajie wrote: > > Hello All, > > > > Top of the day to you. > > > > I have a VPS with CentOs 7. > > I am trying to start-up Tomcat 9.0.27 using "systemctl start tomcat". > And I > > got the error message - "Cannot add dependency job for unit > > systemd-console-setup.service". > > > > I am wondering if there is something I have to setup in my CentOS 7 VPS > or > > if it is an issue with Apache Tomcat 9. > > > > Searching Google for "Cannot add dependency job for unit > systemd-console-setup.service" > gives plenty of results (including you own message to this list), most of > which seem to > refer to some systemd issue in various Linux distributions. > So, on the face of it, it does not look like a tomcat issue. > Maybe an issue of the particular packaged distribution of tomcat that you > are using with > CentOS 7 ? > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Cannot add dependency job for unit systemd-console-setup.service
On 20.10.2019 10:07, Emefile Francis Nwajie wrote: Hello All, Top of the day to you. I have a VPS with CentOs 7. I am trying to start-up Tomcat 9.0.27 using "systemctl start tomcat". And I got the error message - "Cannot add dependency job for unit systemd-console-setup.service". I am wondering if there is something I have to setup in my CentOS 7 VPS or if it is an issue with Apache Tomcat 9. Searching Google for "Cannot add dependency job for unit systemd-console-setup.service" gives plenty of results (including you own message to this list), most of which seem to refer to some systemd issue in various Linux distributions. So, on the face of it, it does not look like a tomcat issue. Maybe an issue of the particular packaged distribution of tomcat that you are using with CentOS 7 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Size Calculation Question
Amazing! That's what I love about Tomcat :) Thank you Luis. On Sun, 20 Oct 2019 at 12:21, Luis Rodríguez Fernández wrote: > Hello M.Manna, > > Yes, probably SESSIONS.ser can give you an idea. Maybe if you want to get > more accurate results perhaps you can > > 1. Do it yourself via JMX [1] > 2. Give a try to psi-probe [2], it seems that it has everything that you > need > > Hope it helps, > > Luis > > [1] > > https://stackoverflow.com/questions/19827650/java-monitor-active-web-sessions > [2] > > https://cwiki.apache.org/confluence/display/tomcat/AddOns#AddOns-WebApplications > > > > > > > El sáb., 19 oct. 2019 a las 2:51, M. Manna () > escribió: > > > Hello, > > > > We are trying to do some calculation for our user session size (or near > > estimate of it). > > > > What we understand is that upon a "Graceful" shutdown, Catalina Host will > > write out the serializable values of all session into a SESSIONS.ser file > > in the main servlet's work directory. If this is correct, then the size > of > > the the SESSIONS.ser file (assuming 1 user has logged in) would probably > > (and approximately) equal to a user's session size? > > > > We do understand that not all the info in the serializable session may > not > > be required. However, given that StandardManager does the privileged load > > based on reading the entire SESSIONS.ser file, we thought it would be a > > more appropriate way of calculating the session size. > > > > Any guidance or help is appreciated, and apologies for making any > incorrect > > assumption. > > > > Thanks, > > > > > -- > > "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." > > - Samuel Beckett >
Re: Adding the manager app to an existing installation
Hello Tom, Hard to say what´s happening without some realm logging. You can have a look here [1]. Hope it helps, Luis [1] https://stackoverflow.com/questions/12311496/how-to-debug-realm-feature-in-tomcat El vie., 18 oct. 2019 a las 18:54, Tom Povey () escribió: > Thanks Olaf, > > Typo in my email. They’re on 8.5.36. I will upgrade them to the latest 8.5. > > Tom > > > On 18 Oct 2019, at 16:45, Olaf Kock wrote: > > > > > > On 18.10.19 17:21, Tom Povey wrote: > >> Hi, > >> > >> I’ve been asked to help with an existing Tomcat install which is > supporting a live website. When it was installed, it did not have the > manager app added. We want to use the manager app now. > >> > >> I have copied the manager folder from another Tomcat install (same > version which is 5.5.36) and updated tomcat-users in the /conf directory > but I can’t login to the manager gui. I give the username and password for > the manager-gui role but it just comes back and redisplays the login prompt. > > > > tomcat-users.xml, as far as I remember, requires restart of the server > > to be taken into account. You didn't mention that you did this. Plus, > > you only said "updated": By default there's no account in there, I'm > > assuming that you "updated" correctly. You might want to post it here > > (bar the actual password). > > > > Plus, your version is 1 day shy of being 7 years old, with the > > end-of-life being even a few more days longer in the past (30 Sep 2012) > > http://tomcat.apache.org/tomcat-55-eol.html > > > > It's about time to move on... > > > > Olaf > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
Re: Session Size Calculation Question
Hello M.Manna, Yes, probably SESSIONS.ser can give you an idea. Maybe if you want to get more accurate results perhaps you can 1. Do it yourself via JMX [1] 2. Give a try to psi-probe [2], it seems that it has everything that you need Hope it helps, Luis [1] https://stackoverflow.com/questions/19827650/java-monitor-active-web-sessions [2] https://cwiki.apache.org/confluence/display/tomcat/AddOns#AddOns-WebApplications El sáb., 19 oct. 2019 a las 2:51, M. Manna () escribió: > Hello, > > We are trying to do some calculation for our user session size (or near > estimate of it). > > What we understand is that upon a "Graceful" shutdown, Catalina Host will > write out the serializable values of all session into a SESSIONS.ser file > in the main servlet's work directory. If this is correct, then the size of > the the SESSIONS.ser file (assuming 1 user has logged in) would probably > (and approximately) equal to a user's session size? > > We do understand that not all the info in the serializable session may not > be required. However, given that StandardManager does the privileged load > based on reading the entire SESSIONS.ser file, we thought it would be a > more appropriate way of calculating the session size. > > Any guidance or help is appreciated, and apologies for making any incorrect > assumption. > > Thanks, > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
IOException: Broken Pipe causes "Calling [asyncError()] is not valid for a request with Async state [MUST_DISPATCH]" to be logged
Hi folks, I have a async response which is designed to run as long as the browser is connected (using SSE). After the browser disconnects and data is written to the response internally a "IOException: Broken Pipe" is thrown, which itself is not logged, but there is some error from the state handling logged (see below) which is quite noisy. Is there somehow to prevent this from happening? or is this a bug? (also happens with tomcat 9.0.27) The spring boot guys also did have a lookt at it: https://github.com/spring-projects/spring-boot/issues/15057 Cheerio Johannes 2018-11-02 11:43:33.016 ERROR 17152 --- [nio-8080-exec-2] o.a.catalina.connector.CoyoteAdapter : Exception while processing an asynchronous request java.lang.IllegalStateException: Calling [asyncError()] is not valid for a request with Async state [MUST_DISPATCH] at org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:440) ~[tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:494) [tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.coyote.Request.action(Request.java:430) ~[tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:382) ~[tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:239) ~[tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.coyote.AbstractProcessor.dispatch(AbstractProcessor.java:241) [tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) [tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770) [tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) [tomcat-embed-core-9.0.12.jar:9.0.12] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.12.jar:9.0.12] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_181] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_181] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.12.jar:9.0.12] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] ``` - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cannot add dependency job for unit systemd-console-setup.service
Hello All, Top of the day to you. I have a VPS with CentOs 7. I am trying to start-up Tomcat 9.0.27 using "systemctl start tomcat". And I got the error message - "Cannot add dependency job for unit systemd-console-setup.service". I am wondering if there is something I have to setup in my CentOS 7 VPS or if it is an issue with Apache Tomcat 9. Thanks for your help.
