Re: tomcat 8.5.23 missing fields: %{cookie} %{Referer} %u in localhost_access_log
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 1/30/20 4:08 PM, Mark Thomas wrote:
> On 30/01/2020 21:00, timfox 123 wrote:
>> Hello The server provides the localhost_access_log files with the
>> following fields missing%{cookie} %{Referer} %u I am
>> using: pattern="%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
>> \"%{User-Agent}i\" \"%{cookie}i\"" />
>>
>> I am running: tomcat 8.5.23openjdk version "1.8.0_232"
>> Redhat 7.7 We are using an internal proxy. Why do we have missing
>> fields in the localhost_access_log ?
>
> Because they are not present in the request sent to Tomcat?
+1
Many browsers are changing the way they handle Referer headers[1], and
some are reconsidering the User-Agent string[2]. I'm not sure what you
are expecting to get from "%{cookie}i", but if it's for a JSESSIONID
cookie, then maybe there is no session (or it's not being represented
by a cookie).
- -chris
[1]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Polic
y
[2]
https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-
chrome/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl40cesACgkQHPApP6U8
pFj3pRAAxjqt7KCwYnX9HcsVQ+eo2dCOr4xJzgv2Cr98y5yOkqvvBw96pbFaWmwt
R8puXhhdTzzbJWdMOYeazpeiUinlKLwnO6h+jJmOMu8jA6s6Rs1JM7A369cOjBJG
5hX6MU16jppbam9uChsQC7vIEvSGYeNW5UVyuBiXZ+D3nfboUlYhL/jciwtss5YR
ZjJ9SONHWNpAuxlCjAWf+oXJUlKfrKakACxDuVR+yADC+d/NNv71pQf5BrJCxD4p
byBnALVjMFRTvA8Ww/O3uJR4j2XSMTYbAbbc1jvZRF3Al0PRgAjh/7xRkJ9xQnOf
voP/44UWIDJvDY1SqOP74Gh8YJPMh0Z921zIXqt/RBolb5pCZRHbERsxRp/7ajg/
zcWmyH224XvvxmP/BW9gHy3cS3LNagg0xg7Ncmx8atv/xP5i1xLu3Dk8NY4cebz0
Pu8hIED8QCZ0dwIIfUDV0n1A4WwMX/JkLsNCQ0Pr6104l4ziuNMZLU+NMeMWN61i
ynkmtwoxfMIKjyE8mgddf0aAAChZ4gd0Z7zh2pNM6Sufl7RpL6yZEZkNRAl6U6AS
LFYLmMG3d4wyjs6EhZECy8pARajLFpqqEvS6uo0lCMAFgCAG5nh0/oJw8CJaYHK+
IUSf7y9+1He1oEqY0gPHxb61pKXSGlZhEIwiX7Y4XrYlGY8gq1A=
=IPF+
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 missing fields: %{cookie} %{Referer} %u in localhost_access_log
On 30/01/2020 21:00, timfox 123 wrote:
> Hello
> The server provides the localhost_access_log files with the following fields
> missing %{cookie} %{Referer} %u
> I am using: pattern="%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
> \"%{User-Agent}i\" \"%{cookie}i\"" />
>
> I am running:
> tomcat 8.5.23 openjdk version "1.8.0_232" Redhat 7.7
> We are using an internal proxy.
> Why do we have missing fields in the localhost_access_log ?
Because they are not present in the request sent to Tomcat?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 8.5.23 missing fields: %{cookie} %{Referer} %u in localhost_access_log
Hello
The server provides the localhost_access_log files with the following fields
missing %{cookie} %{Referer} %u
I am using: pattern="%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\" \"%{cookie}i\"" />
I am running:
tomcat 8.5.23 openjdk version "1.8.0_232" Redhat 7.7
We are using an internal proxy.
Why do we have missing fields in the localhost_access_log ?
Re: tomcat 8.5.23 can not modify maxconcurrentstream setting
> From what I see in the test a STREAM_REFUSED is returned when a the maxConcurrentStream is set to one. Yet I'd like to understand how this value is changed internally. I think >the only difference with my code is the call to the method doHttpUpgrade() which seems to send a GET for upgrade. Does this perform the actual upgrade of the settings? If this >is the case where is it implemented? >Http2UpgradeHandler (which represents an HTTP/2 connection) sets the maximum concurrent stream value when the connection is created: >https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L156 <https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L156> >This means if the value set on the protocol is changed dynamically, the new value takes effect for all subsequent connections. >The setting is communicated to the client as part of the connection preface. >https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L229 <https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L229> >Well-behaved clients will respect this setting but Tomcat checks the limit every time a new stream is created. >https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L1333 <https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L1333> >You may find enabling Tomcat's debug logging for HTTP/2 instructive. >Mark Thanks. I finally understood how it all works. Helena El vie., 1 mar. 2019 a las 10:44, Mark Thomas () escribió: > On 27/02/2019 08:37, Helena Carbajo wrote: > >>> See > >>> > https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 > > > > From what I see in the test a STREAM_REFUSED is returned when a the > maxConcurrentStream is set to one. Yet I'd like to understand how this > value is changed internally. I think the only difference with my code is > the call to the method doHttpUpgrade() which seems to send a GET for > upgrade. Does this perform the actual upgrade of the settings? If this is > the case where is it implemented? > > Http2UpgradeHandler (which represents an HTTP/2 connection) sets the > maximum concurrent stream value when the connection is created: > > > https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L156 > > This means if the value set on the protocol is changed dynamically, the > new value takes effect for all subsequent connections. > > The setting is communicated to the client as part of the connection > preface. > > > https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L229 > > Well-behaved clients will respect this setting but Tomcat checks the > limit every time a new stream is created. > > > https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L1333 > > You may find enabling Tomcat's debug logging for HTTP/2 instructive. > > Mark > > > > > > -Original Message- > > From: Mark Thomas > > Sent: martes, 26 de febrero de 2019 13:45 > > To: users@tomcat.apache.org > > Subject: Re: tomcat 8.5.23 can not modify maxconcurrentstream setting > > > > See > > > https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 > > > > Mark > > > > > > On 26/02/2019 11:01, Helena Carbajo wrote: > >> I'm trying to modify the value of MaxConcurrentStream for the tomcat > server in order to check that it returns a STREAM_REFUSED when the client > uses more streams, but I don't manage to change the default unlimited value. > >> > >> I've been inspecting the tomcat server code with a debugger and I saw > it enters the method protected synchronized void set(Setting setting, Long > value) from the org.apache.coyote.http2.ConnectionSettingsLocal.java class > to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only > modifies the pending hashSet not the current one, which is the one that is > checked later on to determine if it is lower than the clients' active > streams and therefore send the STREAM_REFUSED code. > >> > >> > >> > >> I'm not sure if I'm not modifying the value correctly. I use the > Http2Protocol's method setMaxConcurrentStreams to set the value and then > add the Http2Protocol to the connector(addUpgradeProtocol). > >> > >&
Re: tomcat 8.5.23 can not modify maxconcurrentstream setting
On 27/02/2019 08:37, Helena Carbajo wrote: >>> See >>> https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 > > From what I see in the test a STREAM_REFUSED is returned when a the > maxConcurrentStream is set to one. Yet I'd like to understand how this value > is changed internally. I think the only difference with my code is the call > to the method doHttpUpgrade() which seems to send a GET for upgrade. Does > this perform the actual upgrade of the settings? If this is the case where is > it implemented? Http2UpgradeHandler (which represents an HTTP/2 connection) sets the maximum concurrent stream value when the connection is created: https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L156 This means if the value set on the protocol is changed dynamically, the new value takes effect for all subsequent connections. The setting is communicated to the client as part of the connection preface. https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L229 Well-behaved clients will respect this setting but Tomcat checks the limit every time a new stream is created. https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/http2/Http2UpgradeHandler.java#L1333 You may find enabling Tomcat's debug logging for HTTP/2 instructive. Mark > > -Original Message- > From: Mark Thomas > Sent: martes, 26 de febrero de 2019 13:45 > To: users@tomcat.apache.org > Subject: Re: tomcat 8.5.23 can not modify maxconcurrentstream setting > > See > https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 > > Mark > > > On 26/02/2019 11:01, Helena Carbajo wrote: >> I'm trying to modify the value of MaxConcurrentStream for the tomcat server >> in order to check that it returns a STREAM_REFUSED when the client uses more >> streams, but I don't manage to change the default unlimited value. >> >> I've been inspecting the tomcat server code with a debugger and I saw it >> enters the method protected synchronized void set(Setting setting, Long >> value) from the org.apache.coyote.http2.ConnectionSettingsLocal.java class >> to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only >> modifies the pending hashSet not the current one, which is the one that is >> checked later on to determine if it is lower than the clients' active >> streams and therefore send the STREAM_REFUSED code. >> >> >> >> I'm not sure if I'm not modifying the value correctly. I use the >> Http2Protocol's method setMaxConcurrentStreams to set the value and then add >> the Http2Protocol to the connector(addUpgradeProtocol). >> >> >> >> I'd be grateful if someone could give me a hint of what is going on or what >> I'm doing wrong. Thank you! >> >> > > > - > 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
tomcat 8.5.23 can not modify maxconcurrentstream setting
>> See >> https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 >From what I see in the test a STREAM_REFUSED is returned when a the maxConcurrentStream is set to one. Yet I'd like to understand how this value is changed internally. I think the only difference with my code is the call to the method doHttpUpgrade() which seems to send a GET for upgrade. Does this perform the actual upgrade of the settings? If this is the case where is it implemented?
RE: tomcat 8.5.23 can not modify maxconcurrentstream setting
>> See >> https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 >From what I see in the test a STREAM_REFUSED is returned when a the >maxConcurrentStream is set to one. Yet I'd like to understand how this value >is changed internally. I think the only difference with my code is the call to >the method doHttpUpgrade() which seems to send a GET for upgrade. Does this >perform the actual upgrade of the settings? If this is the case where is it >implemented? -Original Message- From: Mark Thomas Sent: martes, 26 de febrero de 2019 13:45 To: users@tomcat.apache.org Subject: Re: tomcat 8.5.23 can not modify maxconcurrentstream setting See https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 Mark On 26/02/2019 11:01, Helena Carbajo wrote: > I'm trying to modify the value of MaxConcurrentStream for the tomcat server > in order to check that it returns a STREAM_REFUSED when the client uses more > streams, but I don't manage to change the default unlimited value. > > I've been inspecting the tomcat server code with a debugger and I saw it > enters the method protected synchronized void set(Setting setting, Long > value) from the org.apache.coyote.http2.ConnectionSettingsLocal.java class > to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only > modifies the pending hashSet not the current one, which is the one that is > checked later on to determine if it is lower than the clients' active streams > and therefore send the STREAM_REFUSED code. > > > > I'm not sure if I'm not modifying the value correctly. I use the > Http2Protocol's method setMaxConcurrentStreams to set the value and then add > the Http2Protocol to the connector(addUpgradeProtocol). > > > > I'd be grateful if someone could give me a hint of what is going on or what > I'm doing wrong. Thank you! > > - 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: tomcat 8.5.23 can not modify maxconcurrentstream setting
See https://github.com/apache/tomcat/blob/8.5.x/test/org/apache/coyote/http2/TestHttp2Section_5_1.java#L174 Mark On 26/02/2019 11:01, Helena Carbajo wrote: > I'm trying to modify the value of MaxConcurrentStream for the tomcat server > in order to check that it returns a STREAM_REFUSED when the client uses more > streams, but I don't manage to change the default unlimited value. > > I've been inspecting the tomcat server code with a debugger and I saw it > enters the method protected synchronized void set(Setting setting, Long > value) from the org.apache.coyote.http2.ConnectionSettingsLocal.java class > to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only > modifies the pending hashSet not the current one, which is the one that is > checked later on to determine if it is lower than the clients' active streams > and therefore send the STREAM_REFUSED code. > > > > I'm not sure if I'm not modifying the value correctly. I use the > Http2Protocol's method setMaxConcurrentStreams to set the value and then add > the Http2Protocol to the connector(addUpgradeProtocol). > > > > I'd be grateful if someone could give me a hint of what is going on or what > I'm doing wrong. Thank you! > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 8.5.23 can not modify maxconcurrentstream setting
I'm trying to modify the value of MaxConcurrentStream for the tomcat server in order to check that it returns a STREAM_REFUSED when the client uses more streams, but I don't manage to change the default unlimited value. I've been inspecting the tomcat server code with a debugger and I saw it enters the method protected synchronized void set(Setting setting, Long value) from the org.apache.coyote.http2.ConnectionSettingsLocal.java class to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only modifies the pending hashSet not the current one, which is the one that is checked later on to determine if it is lower than the clients' active streams and therefore send the STREAM_REFUSED code. I'm not sure if I'm not modifying the value correctly. I use the Http2Protocol's method setMaxConcurrentStreams to set the value and then add the Http2Protocol to the connector(addUpgradeProtocol). I'd be grateful if someone could give me a hint of what is going on or what I'm doing wrong. Thank you!
tomcat 8.5.23 not modifying maxconcurrentstream setting
I'm trying to modify the value of MaxConcurrentStream for the tomcat server in
order to check that it returns a STREAM_REFUSED when the client uses more
streams, but I don't manage to change the default unlimited value.
I've been inspecting the tomcat server code with a debugger and I saw it enters
this method from the org.apache.coyote.http2.ConnectionSettingsLocal.java class
to change the value for maxConcurrentStream. Yet, if I'm not wrong, it only
modifies the pending hashSet not the current one, which is the one that is
checked later on to determine if it is lower than the clients' active streams
and therefore send the STREAM_REFUSED code.
@Override
protected synchronized void set(Setting setting, Long value) {
checkSend();
if (current.get(setting).longValue() == value.longValue()) {
pending.remove(setting);
} else {
pending.put(setting, value);
}
}
I'm not sure if I'm not modifying the value correctly, so here it's the code I
use to set the value:
Http2Protocol http2 = new Http2Protocol();
http2.setMaxConcurrentStreams(2);
...
connector.addUpgradeProtocol(http2);
I'd be grateful if someone could give me a hint of what is going on or what I'm
doing wrong. Thank you!
Re: Server Name Identification (SNI) configuration Tomcat 8.5.23
On Tue, Feb 12, 2019 at 11:37 AM Herb Burnswell wrote: > > > On Tue, Feb 12, 2019 at 11:26 AM Mark Thomas wrote: > >> On 12/02/2019 19:21, Herb Burnswell wrote: >> > All, >> > >> > Tomcat: 8.5.23 >> > OS: RHEL 7.5 >> > >> > I am attempting to set up Tomcat to use two keystore's with SNI. Tomcat >> > starts successfully but but I receive a timeout when trying to access >> > either of the defined server names. >> >> >> >> > As mentioned, Tomcat start successfully, but the sites time out. There >> is >> > nothing in the logs that indicate a request is even made. >> > >> > Am I missing something in this configuration? Any guidance is greatly >> > appreciated. >> >> What do the logs say when Tomcat starts with the non-working >> configuration? >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > Thanks for the reply Mark. Unfortunately there no extra information in > the logs from the non-working configuration. It appears that everything > starts successfully with working and non-working configuration. > > As mentioned, the timeout attempting to connect to the SNI domains does > not register in the logs either. > > HB > Damn, my bad. I figured it out. Embarrassingly, I had an incorrect password for one of the keystores. I was focusing so much on the configuration parameters I overlooked the simple part. Thanks, HB
Re: Server Name Identification (SNI) configuration Tomcat 8.5.23
On Tue, Feb 12, 2019 at 11:26 AM Mark Thomas wrote: > On 12/02/2019 19:21, Herb Burnswell wrote: > > All, > > > > Tomcat: 8.5.23 > > OS: RHEL 7.5 > > > > I am attempting to set up Tomcat to use two keystore's with SNI. Tomcat > > starts successfully but but I receive a timeout when trying to access > > either of the defined server names. > > > > > As mentioned, Tomcat start successfully, but the sites time out. There > is > > nothing in the logs that indicate a request is even made. > > > > Am I missing something in this configuration? Any guidance is greatly > > appreciated. > > What do the logs say when Tomcat starts with the non-working configuration? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks for the reply Mark. Unfortunately there no extra information in the logs from the non-working configuration. It appears that everything starts successfully with working and non-working configuration. As mentioned, the timeout attempting to connect to the SNI domains does not register in the logs either. HB
Re: Server Name Identification (SNI) configuration Tomcat 8.5.23
On 12/02/2019 19:21, Herb Burnswell wrote: > All, > > Tomcat: 8.5.23 > OS: RHEL 7.5 > > I am attempting to set up Tomcat to use two keystore's with SNI. Tomcat > starts successfully but but I receive a timeout when trying to access > either of the defined server names. > As mentioned, Tomcat start successfully, but the sites time out. There is > nothing in the logs that indicate a request is even made. > > Am I missing something in this configuration? Any guidance is greatly > appreciated. What do the logs say when Tomcat starts with the non-working configuration? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Server Name Identification (SNI) configuration Tomcat 8.5.23
All, Tomcat: 8.5.23 OS: RHEL 7.5 I am attempting to set up Tomcat to use two keystore's with SNI. Tomcat starts successfully but but I receive a timeout when trying to access either of the defined server names. Here is a single server name configuration that works successfully: Here is the SNI configuration that I'm trying: As mentioned, Tomcat start successfully, but the sites time out. There is nothing in the logs that indicate a request is even made. Am I missing something in this configuration? Any guidance is greatly appreciated. Best, HB
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Hi.
Glad if I could be of even limited help.
It would be nice if you sent to the list a complete layout of your solution, to put into
the Tomcat FAQ (e.g. like here : https://wiki.apache.org/tomcat/HowTo, in section 3
Configuration)
That may help someone else in the future.
On 20.09.2018 15:38, Thomas Delaney wrote:
André,
I was able to use the reference you made about making tomcatAuthentication
false. With this Tomcat setting combined with HTTPD's mod_proxy_ajp proxy
rules I was able to get this working. I am still testing this but looks
clear to me that this is the solution. Thanks for the quick responses
yesterday!
On Wed, Sep 19, 2018 at 5:10 PM André Warnier (tomcat)
wrote:
Hi.
Much better..
I don't know if I will be able to help you, considering my little
knowledge of Kerberos,
but I'm sure that someone else now will be.
On 19.09.2018 16:08, Thomas Delaney wrote:
Here is more detail into what I went through for setting up Apache
Tomcat.:
I configured each Apache Tomcat instance using this bit of documentation:
SPNEGO
http://spnego.sourceforge.net/
I also used this documentation in order to get my workstation to accept
Kerberos authentication and not default to NTLM.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
*I created/configured the following based on what was outlined from the
SPNEGO doc:*
login.conf
krb.conf
HelloKDC.java successfully connected when testing
The SPNEGO filter in Apache Tomcat's web.xml
Took the source code for spnego.jar and placed it in Apache Tomcat's
library
hello_spnego.jsp successfully displayed the correct remote user on the
web
page
hello_delegate.jsp successfully displayed the correct delegated
credentials
on the webpage.
Ok, so we can assume
- that the basic Kerberos infrastructure works
- that you know how to set it up
- and that it works when you do the Kerberos authentication in Tomcat
itself, and access
tomcat directly from the browser.
Once I was able to verify that the above steps worked on Apache Tomcat. I
tested the same web pages on Apache HTTPD.
You mean "when accessing Tomcat /through/ the Apache httpd front-end,
right ?
From your original description, I thought that you wanted to do the
Kerberos
authentication in the front-end Apache httpd, and pass on the
authenticated user-id to the
back-end Tomcats then. That's still an option anyway.
But from the description below it looks like you want to keep the
SPNEGO/Kerberos
authentication at the Tomcat level, and just want the front-end httpd to
be "transparent"
with respect to the Kerberos authentication exchanges.
Do I get this right ?
I ran into issues when testing
hello_spnego.jsp and hello_delegate.jsp.
Here have been my results:
hello_spnego.jsp -> "hello root !" (root being a unix user and not the
AD/Windows user signed onto the domain).
hello_delegate.jsp -> "No delegated creds."
*Here is the section of the SPNEGO doc source on how to setup
hello_delegation.jsp and create hello_spnego.jsp:*
http://spnego.sourceforge.net/credential_delegation.html
Mmm. This is quite complicated, but I think that I'm starting to guess
what the problem is.
I think that "delegation" is not really what you want to do here. It might
work in the
absolute (if everything was set up correctly to do it), but I believe that
it is overkill
in your case; and I believe that you are missing one piece of the puzzle
anyway.
Taking into account my total lack of experience with SPNEGO/Kerberos
delegation - and thus
taking this with a grain of salt - I believe (from the above documentation
page) that for
such a delegation to work with an Apache httpd front-end, your browser
would /first/ need
to be authenticated already by the front-end (for example, "as you"), and
that this
front-end /itself/ would need to have /its own (separate) account/ in your
infrastructure
- and an account with special properties - in order to be allowed to
authenticate "as you"
(otherwise said : "impersonate you") with the Tomcat back-end's
SPNEGO/Kerberos Valve.
*Here is how I have Apache HTTPD forwarding requests to Tomcat. *
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED
BalancerMember "http://localhost:8081/application"; route=node1
BalancerMember "http://localhost:8082/application"; route=node2
BalancerMember "http://localhost:8083/application"; route=node3
ProxySet lbmethod=byrequests stickysession=ROUTEID
ProxyPass /application balancer://application/
ProxyPassReverse /application balancer://application/
What you are setting up here is a standard Apache httpd "reverse proxy
+ load-balancer". But, as far as I can see from the above, this proxy
does not (itself)
authenticate the browsers which talk to it.
So this front-end proxy does not really have a (browser-originating)
user-id for which it
would be able to request a "delegated authentication".
And it is also not set up
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
André,
I was able to use the reference you made about making tomcatAuthentication
false. With this Tomcat setting combined with HTTPD's mod_proxy_ajp proxy
rules I was able to get this working. I am still testing this but looks
clear to me that this is the solution. Thanks for the quick responses
yesterday!
On Wed, Sep 19, 2018 at 5:10 PM André Warnier (tomcat)
wrote:
> Hi.
> Much better..
> I don't know if I will be able to help you, considering my little
> knowledge of Kerberos,
> but I'm sure that someone else now will be.
>
> On 19.09.2018 16:08, Thomas Delaney wrote:
> > Here is more detail into what I went through for setting up Apache
> Tomcat.:
> > I configured each Apache Tomcat instance using this bit of documentation:
> > SPNEGO
> > http://spnego.sourceforge.net/
> >
> > I also used this documentation in order to get my workstation to accept
> > Kerberos authentication and not default to NTLM.
> >
> https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
> >
> > *I created/configured the following based on what was outlined from the
> > SPNEGO doc:*
> > login.conf
> > krb.conf
> > HelloKDC.java successfully connected when testing
> > The SPNEGO filter in Apache Tomcat's web.xml
> > Took the source code for spnego.jar and placed it in Apache Tomcat's
> library
> > hello_spnego.jsp successfully displayed the correct remote user on the
> web
> > page
> > hello_delegate.jsp successfully displayed the correct delegated
> credentials
> > on the webpage.
>
> Ok, so we can assume
> - that the basic Kerberos infrastructure works
> - that you know how to set it up
> - and that it works when you do the Kerberos authentication in Tomcat
> itself, and access
> tomcat directly from the browser.
>
> >
> > Once I was able to verify that the above steps worked on Apache Tomcat. I
> > tested the same web pages on Apache HTTPD.
>
> You mean "when accessing Tomcat /through/ the Apache httpd front-end,
> right ?
>
> From your original description, I thought that you wanted to do the
> Kerberos
> authentication in the front-end Apache httpd, and pass on the
> authenticated user-id to the
> back-end Tomcats then. That's still an option anyway.
> But from the description below it looks like you want to keep the
> SPNEGO/Kerberos
> authentication at the Tomcat level, and just want the front-end httpd to
> be "transparent"
> with respect to the Kerberos authentication exchanges.
> Do I get this right ?
>
> I ran into issues when testing
> > hello_spnego.jsp and hello_delegate.jsp.
> >
> > Here have been my results:
> > hello_spnego.jsp -> "hello root !" (root being a unix user and not the
> > AD/Windows user signed onto the domain).
> > hello_delegate.jsp -> "No delegated creds."
> >
> > *Here is the section of the SPNEGO doc source on how to setup
> > hello_delegation.jsp and create hello_spnego.jsp:*
> > http://spnego.sourceforge.net/credential_delegation.html
>
> Mmm. This is quite complicated, but I think that I'm starting to guess
> what the problem is.
> I think that "delegation" is not really what you want to do here. It might
> work in the
> absolute (if everything was set up correctly to do it), but I believe that
> it is overkill
> in your case; and I believe that you are missing one piece of the puzzle
> anyway.
>
> Taking into account my total lack of experience with SPNEGO/Kerberos
> delegation - and thus
> taking this with a grain of salt - I believe (from the above documentation
> page) that for
> such a delegation to work with an Apache httpd front-end, your browser
> would /first/ need
> to be authenticated already by the front-end (for example, "as you"), and
> that this
> front-end /itself/ would need to have /its own (separate) account/ in your
> infrastructure
> - and an account with special properties - in order to be allowed to
> authenticate "as you"
> (otherwise said : "impersonate you") with the Tomcat back-end's
> SPNEGO/Kerberos Valve.
>
> >
> > *Here is how I have Apache HTTPD forwarding requests to Tomcat. *
> > Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
> > env=BALANCER_ROUTE_CHANGED
> >
> > BalancerMember "http://localhost:8081/application"; route=node1
> > BalancerMember "http://localhost:8082/application"; route=node2
> > BalancerMember "http://localhost:8083/application"; route=node3
> > ProxySet lbmethod=byrequests stickysession=ROUTEID
> >
> >
> > ProxyPass /application balancer://application/
> > ProxyPassReverse /application balancer://application/
> >
>
> What you are setting up here is a standard Apache httpd "reverse proxy
> + load-balancer". But, as far as I can see from the above, this proxy
> does not (itself)
> authenticate the browsers which talk to it.
>
> So this front-end proxy does not really have a (browser-originating)
> user-id for which it
> would be able to request a "delegated authentication".
> And it is also not set up to do "delegated authentication" with
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Hi.
Much better..
I don't know if I will be able to help you, considering my little knowledge of Kerberos,
but I'm sure that someone else now will be.
On 19.09.2018 16:08, Thomas Delaney wrote:
Here is more detail into what I went through for setting up Apache Tomcat.:
I configured each Apache Tomcat instance using this bit of documentation:
SPNEGO
http://spnego.sourceforge.net/
I also used this documentation in order to get my workstation to accept
Kerberos authentication and not default to NTLM.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
*I created/configured the following based on what was outlined from the
SPNEGO doc:*
login.conf
krb.conf
HelloKDC.java successfully connected when testing
The SPNEGO filter in Apache Tomcat's web.xml
Took the source code for spnego.jar and placed it in Apache Tomcat's library
hello_spnego.jsp successfully displayed the correct remote user on the web
page
hello_delegate.jsp successfully displayed the correct delegated credentials
on the webpage.
Ok, so we can assume
- that the basic Kerberos infrastructure works
- that you know how to set it up
- and that it works when you do the Kerberos authentication in Tomcat itself, and access
tomcat directly from the browser.
Once I was able to verify that the above steps worked on Apache Tomcat. I
tested the same web pages on Apache HTTPD.
You mean "when accessing Tomcat /through/ the Apache httpd front-end, right ?
From your original description, I thought that you wanted to do the Kerberos
authentication in the front-end Apache httpd, and pass on the authenticated user-id to the
back-end Tomcats then. That's still an option anyway.
But from the description below it looks like you want to keep the SPNEGO/Kerberos
authentication at the Tomcat level, and just want the front-end httpd to be "transparent"
with respect to the Kerberos authentication exchanges.
Do I get this right ?
I ran into issues when testing
hello_spnego.jsp and hello_delegate.jsp.
Here have been my results:
hello_spnego.jsp -> "hello root !" (root being a unix user and not the
AD/Windows user signed onto the domain).
hello_delegate.jsp -> "No delegated creds."
*Here is the section of the SPNEGO doc source on how to setup
hello_delegation.jsp and create hello_spnego.jsp:*
http://spnego.sourceforge.net/credential_delegation.html
Mmm. This is quite complicated, but I think that I'm starting to guess what
the problem is.
I think that "delegation" is not really what you want to do here. It might work in the
absolute (if everything was set up correctly to do it), but I believe that it is overkill
in your case; and I believe that you are missing one piece of the puzzle anyway.
Taking into account my total lack of experience with SPNEGO/Kerberos delegation - and thus
taking this with a grain of salt - I believe (from the above documentation page) that for
such a delegation to work with an Apache httpd front-end, your browser would /first/ need
to be authenticated already by the front-end (for example, "as you"), and that this
front-end /itself/ would need to have /its own (separate) account/ in your infrastructure
- and an account with special properties - in order to be allowed to authenticate "as you"
(otherwise said : "impersonate you") with the Tomcat back-end's SPNEGO/Kerberos Valve.
*Here is how I have Apache HTTPD forwarding requests to Tomcat. *
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED
BalancerMember "http://localhost:8081/application"; route=node1
BalancerMember "http://localhost:8082/application"; route=node2
BalancerMember "http://localhost:8083/application"; route=node3
ProxySet lbmethod=byrequests stickysession=ROUTEID
ProxyPass /application balancer://application/
ProxyPassReverse /application balancer://application/
What you are setting up here is a standard Apache httpd "reverse proxy
+ load-balancer". But, as far as I can see from the above, this proxy does not (itself)
authenticate the browsers which talk to it.
So this front-end proxy does not really have a (browser-originating) user-id for which it
would be able to request a "delegated authentication".
And it is also not set up to do "delegated authentication" with the back-end Tomcat's
SPNEGO/Krberos Valve.
This may be a bit confusing, and maybe this article explains it better than I
could :
https://blogs.informatica.com/2018/05/07/the-kerberos-conundrum-a-proxys-plight/#fbid=UtL4Ic19fwv
(Obviously, this is talking about some other front-end proxy software, but you can see
that one needs something additional on the front-end proxy, to do this kind of thing).
All in all, if all that you need is that the application installed under Tomcat would be
able to obtain an authenticated "current user-id", I would suggest that instead of trying
to configure this using impersonation/delegation, you try something
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Here is more detail into what I went through for setting up Apache Tomcat.:
I configured each Apache Tomcat instance using this bit of documentation:
SPNEGO
http://spnego.sourceforge.net/
I also used this documentation in order to get my workstation to accept
Kerberos authentication and not default to NTLM.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM
*I created/configured the following based on what was outlined from the
SPNEGO doc:*
login.conf
krb.conf
HelloKDC.java successfully connected when testing
The SPNEGO filter in Apache Tomcat's web.xml
Took the source code for spnego.jar and placed it in Apache Tomcat's library
hello_spnego.jsp successfully displayed the correct remote user on the web
page
hello_delegate.jsp successfully displayed the correct delegated credentials
on the webpage.
Once I was able to verify that the above steps worked on Apache Tomcat. I
tested the same web pages on Apache HTTPD. I ran into issues when testing
hello_spnego.jsp and hello_delegate.jsp.
Here have been my results:
hello_spnego.jsp -> "hello root !" (root being a unix user and not the
AD/Windows user signed onto the domain).
hello_delegate.jsp -> "No delegated creds."
*Here is the section of the SPNEGO doc source on how to setup
hello_delegation.jsp and create hello_spnego.jsp:*
http://spnego.sourceforge.net/credential_delegation.html
*Here is how I have Apache HTTPD forwarding requests to Tomcat. *
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED
BalancerMember "http://localhost:8081/application"; route=node1
BalancerMember "http://localhost:8082/application"; route=node2
BalancerMember "http://localhost:8083/application"; route=node3
ProxySet lbmethod=byrequests stickysession=ROUTEID
ProxyPass /application balancer://application/
ProxyPassReverse /application balancer://application/
On Wed, Sep 19, 2018 at 7:57 AM André Warnier (tomcat)
wrote:
> On 18.09.2018 23:24, Thomas Delaney wrote:
> > Hello All,
> >
> > I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3
> server
> > to get Kerberos SSO working with a web client application. I have also in
> > addition configured Apache HTTPD 2.4.29 on the same machine.When I reach
> > that website I am failing to get SSO working. The web server is not
> passing
> > off the delegation credentials to Apache Tomcat server. I have the web
> > server load balance proxying it's request to multiple Apache Tomcat
> > instances. I have tried applying mody_proxy_http environment variables,
> but
> > the site continues to fail SSO. Is there a guide or configuration that
> > HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off
> > delegation credentials to Apache Tomcat?
> >
>
> If you would like someone here to be able to help you, you would need to
> be much more
> precise than that. You write "I have done this" and "I have done that",
> but without
> giving any clue as to /how/ you did this or that.
> You are not even saying /where/ you have configured the Kerberos SSO.
> Under the Apache
> httpd front-end ? or under Tomcat ?
>
> To point you nevertheless in a possible direction, read this :
>
> https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Apache_httpd
> (and, in your mind, substitute "Windows authentication" by "Kerberos
> authentication")
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
On 19.09.2018 13:57, André Warnier (tomcat) wrote: On 18.09.2018 23:24, Thomas Delaney wrote: Hello All, I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3 server to get Kerberos SSO working with a web client application. I have also in addition configured Apache HTTPD 2.4.29 on the same machine.When I reach that website I am failing to get SSO working. The web server is not passing off the delegation credentials to Apache Tomcat server. I have the web server load balance proxying it's request to multiple Apache Tomcat instances. I have tried applying mody_proxy_http environment variables, but the site continues to fail SSO. Is there a guide or configuration that HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off delegation credentials to Apache Tomcat? If you would like someone here to be able to help you, you would need to be much more precise than that. You write "I have done this" and "I have done that", but without giving any clue as to /how/ you did this or that. You are not even saying /where/ you have configured the Kerberos SSO. Under the Apache httpd front-end ? or under Tomcat ? To point you nevertheless in a possible direction, read this : https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Apache_httpd (and, in your mind, substitute "Windows authentication" by "Kerberos authentication") Addendum : Searching Google for "tomcat REMOTE_USER" shows quite a few relevant links. Unfortunately, none of them seems to point directly to the particular combination you are looking for, but by combining them you will get a pretty good idea of how this could work. One solution which would certainly work out of the box is this : browser <= HTTP(S) => Apache httpd <= AJP => Tomcat AJP Connector + mod_proxy(with "tomcatAuthentication="false") + mod_proxy_ajp (or mod_jk) + mod_(whatever-authentication) In a nutshell : that is because when Apache httpd authenticates a user (via whichever authentication method is configured there), then subsequently proxies this request to Tomcat via AJP, then in the AJP request to Tomcat, the authenticated user-id is passed along. The Tomcat AJP Connector then picks this up, and sets the Tomcat authenticated user to that same value. Note that this (along with any other solution which passes the httpd-authenticated user along with the request to the back-end tomcat server) is only as secure as the connection itself between the front-end Apache httpd and the back-end Tomcat. Unfortunately, the Tomcat AJP Connector seems to be the only one to offer such an option "out of the box", and the HTTP Connectors don't seem to offer that. There is a long discussion about this here : http://tomcat.10.x6.nabble.com/Tomcat-REMOTE-USER-getRemoteUser-td5037513.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
On 18.09.2018 23:24, Thomas Delaney wrote: Hello All, I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3 server to get Kerberos SSO working with a web client application. I have also in addition configured Apache HTTPD 2.4.29 on the same machine.When I reach that website I am failing to get SSO working. The web server is not passing off the delegation credentials to Apache Tomcat server. I have the web server load balance proxying it's request to multiple Apache Tomcat instances. I have tried applying mody_proxy_http environment variables, but the site continues to fail SSO. Is there a guide or configuration that HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off delegation credentials to Apache Tomcat? If you would like someone here to be able to help you, you would need to be much more precise than that. You write "I have done this" and "I have done that", but without giving any clue as to /how/ you did this or that. You are not even saying /where/ you have configured the Kerberos SSO. Under the Apache httpd front-end ? or under Tomcat ? To point you nevertheless in a possible direction, read this : https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Apache_httpd (and, in your mind, substitute "Windows authentication" by "Kerberos authentication") - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
HTTPD pass off delegation credentials to Apache Tomcat 8.5.23 for SSO Kerberos
Hello All, I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3 server to get Kerberos SSO working with a web client application. I have also in addition configured Apache HTTPD 2.4.29 on the same machine.When I reach that website I am failing to get SSO working. The web server is not passing off the delegation credentials to Apache Tomcat server. I have the web server load balance proxying it's request to multiple Apache Tomcat instances. I have tried applying mody_proxy_http environment variables, but the site continues to fail SSO. Is there a guide or configuration that HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off delegation credentials to Apache Tomcat? Thanks!
Re: [External] RE: Tomcat 8.5.23
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lawrence, On 2/27/18 12:42 PM, Lawrence Lim wrote: > Our company's standard is Java 8. That's the main reason for > choosing Tomcat 8 over the latest. I think Felix was asking why you were installing Tomcat 8.5.23 instead of Tomcat 8.5.28. Also, Tomcat 9 runs just fine on Java 8. In fact, it's a requirement that Tomcat 9 run on Java 8. I personally wouldn't run Tomcat 9 in production just yet, but that's just because I'm ultra-paranoid. > I configured all the users and privileges in the tomcat manager > xml file manually using a text editor right after I unpack tomcat > 8. Great. So what does it look like, now? Remember to remove secrets. > I have looked at all the tomcat log files and it seems like it's > logging when I undeploy but not logging anything when I deploy. There should be a bunch of logging happening during deployment. Tomcat will at least say "deploying context [/yourapp]" and then tell you when it's done deploying. Plus any errors that may occur during the process. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVy3cACgkQHPApP6U8 pFhFuQ/+Ko5wHjJeqKyUJi8qLZL+/EdDYJ86wAouvbGd5jDKE1sXMVVge66bqVnB wKgiK3IrFc+fDxhaWTgGm4mHgGbxKuFeo7J+PsPIo6Db8ldn0D3JbM4WMelsNM4X EC2/VfuZmRe7eGtqyVl6xkHp3AozDlAZwe62upKs9+N08KMXhxvP2jYcDXSOn76v MUohnevcO4o3TIHRxpFkwU+lXU4PXFaFV64QOC+MH57uS05JvGS6CBT9AhMRUqtr ryJS2UR1WdcNXnPKPZ12JAneOl/cL8qMJf+5INZZVqllXbLV+JpyPODckCLgo8pc W7RvZjAV1RHp1Z3WlfJuh7J4QlgOz01tU2ee0qjNxk8l+D0ubtDJnDkIBxLSoEY0 zH3cC9nkvwAOhN7A5JzEJTW0nzE5NvZJfM5egFfIXTXEPQRINXQco8rIh1SqyLkO 9xSsYphrvOVDKXEOeghalsU0mEDI+3ci1/79v+tQgaON5neG7E/+9eGTNsYjsuR8 6S9lKM86UAviH3s/WoSdRCDZVqph8oEMPM9We30UKRdtz9FFKZdiX5dOnOahiQVf lTHNC7o33PoXIXttDeWb2c3i4zl1zZDlMIOHsTs5ZrCMwrjBxUES5iNOPV7mM+Tl kirCitsCsU0gtxIaI8FuLFkNTy/Ui6i0R75lwXG7qwlaF7N4gF0= =rW8V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [External] RE: Tomcat 8.5.23
Our company's standard is Java 8. That's the main reason for choosing Tomcat 8
over the latest. I configured all the users and privileges in the tomcat
manager xml file manually using a text editor right after I unpack tomcat 8.
I have looked at all the tomcat log files and it seems like it's logging when I
undeploy but not logging anything when I deploy.
Regards,
Lawrence Lim
Software Developer
—
ENBRIDGE
TEL: 780-969-6208
10175 101 St NW, Edmonton, Alberta T5J 0H3
enbridge.com
Integrity. Safety. Respect.
-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Sunday, February 25, 2018 3:44 AM
To: users@tomcat.apache.org
Subject: Re: [External] RE: Tomcat 8.5.23
Am Freitag, den 23.02.2018, 15:26 + schrieb Lawrence Lim:
> I installed tomcat via untar, something tar -zxf apache-tomcat-
> 8.5.23.tar.gz.
Any reason for not using the latest available tomcat?
>
> I am running Java 8 and no security manager I know of.
OK
>
> I already did a chmod 777 in the tomcat directory.
It is probably not a good idea to set any directory to word-writable,
especially if it contains server software.
The permissions on the directories of the unpacked tar should be correct for
the user that unpacked it.
What have you done after unpacking tomcat?
Did you configure the Realm (for example by having a look at
conf/tomcat-users.xml and adding the required users, roles and passwords)?
There is quite some documentation available under http://tomcat.apache.
org/tomcat-8.5-doc/manager-howto.html
Have you looked at all log files in the logs dir?
Regards,
Felix
>
> Regards,
>
> Lawrence Lim
> Software Developer
> —
>
> ENBRIDGE
> TEL: 780-969-6208
> 10175 101 St NW, Edmonton, Alberta T5J 0H3
>
> enbridge.com
> Integrity. Safety. Respect.
>
>
> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Thursday, February 22, 2018 11:45 PM
> To: Tomcat Users List
> Subject: [External] RE: Tomcat 8.5.23
>
>
>
> Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim nbridge.com>:
> >
> > Red Hat Enterprise Linux Server release 6.9 (Santiago)
> How did you install tomcat?
> Are you running tomcat with some kind of security manager enabled
> (Java or system wide)?
> Can the tomcat user (running the process) write to the filesystem?
>
> Regards,
> Felix
>
> >
> >
> > Yes. I did check the logs. It does not log anything when I deploy.
> > But,
> > it logs something when I undeploy.
> >
> > Lawrence Lim
> > Software Developer
> > -
> >
> > ENBRIDGE
> > TEL: 780-969-6208
> > 10175 101 St NW, Edmonton, Alberta T5J 0H3
> >
> > enbridge.com
> > Integrity. Safety. Respect.
> >
> > -Original Message-
> > From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
> > Sent: Thursday, February 15, 2018 10:58 AM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Tomcat 8.5.23
> >
> > Which operating system?
> > Did you check the logs?
> >
> > Sent using OWA for iPhone
> >
> > From: Lawrence Lim
> > Sent: Thursday, February 15, 2018 11:09:54 PM
> > To: users@tomcat.apache.org
> > Subject: Tomcat 8.5.23
> >
> > Hi,
> >
> >
> >
> > I just installed tomcat 8.5.23. I am having problems deploying web
> > apps via manager. To reproduce:
> >
> >
> >
> > 1. Login to tomcat manager
> >
> >
> >
> > 2. Go to " WAR file to deploy"
> >
> >
> >
> > 3. Pick a war file
> >
> >
> >
> >
> >
> > Error message: FAIL - File upload failed, no file
> >
> >
> >
> >
> >
> > Workaround: Copy war file to the tomcat webapps directory
> >
> >
> >
> >
> >
> > I also tried using localhost:8080, same result. So, it's not some
> > weird networking constraint.
> >
> >
> > Lawrence Lim
> > Software Developer
> > -
> >
> > ENBRIDGE
> > TEL: 780-969-6208
> > 10175 101 St NW, Edmonton, Alberta T5J 0H3
> >
> > enbridge.com
> > Integrity. Safety. Respect.
> >
> > ::DISCLAIMER::
> > ___
> >
> > _
> > Confidentiality Notice from Dixons Carphone plc (registered in
> > England & Wales No.07105905) of 1 Portal Way, London, W3 6RS
> > ("Dixons Carphone
Re: [External] RE: Tomcat 8.5.23
Am Freitag, den 23.02.2018, 15:26 + schrieb Lawrence Lim:
> I installed tomcat via untar, something tar -zxf apache-tomcat-
> 8.5.23.tar.gz.
Any reason for not using the latest available tomcat?
>
> I am running Java 8 and no security manager I know of.
OK
>
> I already did a chmod 777 in the tomcat directory.
It is probably not a good idea to set any directory to word-writable,
especially if it contains server software.
The permissions on the directories of the unpacked tar should be
correct for the user that unpacked it.
What have you done after unpacking tomcat?
Did you configure the Realm (for example by having a look at
conf/tomcat-users.xml and adding the required users, roles and
passwords)?
There is quite some documentation available under http://tomcat.apache.
org/tomcat-8.5-doc/manager-howto.html
Have you looked at all log files in the logs dir?
Regards,
Felix
>
> Regards,
>
> Lawrence Lim
> Software Developer
> —
>
> ENBRIDGE
> TEL: 780-969-6208
> 10175 101 St NW, Edmonton, Alberta T5J 0H3
>
> enbridge.com
> Integrity. Safety. Respect.
>
>
> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Thursday, February 22, 2018 11:45 PM
> To: Tomcat Users List
> Subject: [External] RE: Tomcat 8.5.23
>
>
>
> Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim nbridge.com>:
> >
> > Red Hat Enterprise Linux Server release 6.9 (Santiago)
> How did you install tomcat?
> Are you running tomcat with some kind of security manager enabled
> (Java or system wide)?
> Can the tomcat user (running the process) write to the filesystem?
>
> Regards,
> Felix
>
> >
> >
> > Yes. I did check the logs. It does not log anything when I deploy.
> > But,
> > it logs something when I undeploy.
> >
> > Lawrence Lim
> > Software Developer
> > -
> >
> > ENBRIDGE
> > TEL: 780-969-6208
> > 10175 101 St NW, Edmonton, Alberta T5J 0H3
> >
> > enbridge.com
> > Integrity. Safety. Respect.
> >
> > -Original Message-
> > From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
> > Sent: Thursday, February 15, 2018 10:58 AM
> > To: users@tomcat.apache.org
> > Subject: [External] Re: Tomcat 8.5.23
> >
> > Which operating system?
> > Did you check the logs?
> >
> > Sent using OWA for iPhone
> >
> > From: Lawrence Lim
> > Sent: Thursday, February 15, 2018 11:09:54 PM
> > To: users@tomcat.apache.org
> > Subject: Tomcat 8.5.23
> >
> > Hi,
> >
> >
> >
> > I just installed tomcat 8.5.23. I am having problems deploying web
> > apps
> > via manager. To reproduce:
> >
> >
> >
> > 1. Login to tomcat manager
> >
> >
> >
> > 2. Go to " WAR file to deploy"
> >
> >
> >
> > 3. Pick a war file
> >
> >
> >
> >
> >
> > Error message: FAIL - File upload failed, no file
> >
> >
> >
> >
> >
> > Workaround: Copy war file to the tomcat webapps directory
> >
> >
> >
> >
> >
> > I also tried using localhost:8080, same result. So, it's not some
> > weird
> > networking constraint.
> >
> >
> > Lawrence Lim
> > Software Developer
> > -
> >
> > ENBRIDGE
> > TEL: 780-969-6208
> > 10175 101 St NW, Edmonton, Alberta T5J 0H3
> >
> > enbridge.com
> > Integrity. Safety. Respect.
> >
> > ::DISCLAIMER::
> > ___
> >
> > _
> > Confidentiality Notice from Dixons Carphone plc (registered in
> > England
> > & Wales No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons
> > Carphone"). The information contained in this e-mail and any
> > attachments may be legally privileged, proprietary and/or
> > confidential.
> > If you received this e-mail in error, please notify the sender by
> > return, permanently delete the e-mail and destroy all hard copies
> > immediately. No warranty is made as to the completeness or accuracy
> > of
> > the information contained in this e-mail. Opinions, conclusions
> > and
> > sta
Re: Tomcat 8.5.23
On 16 Feb 2018 4:40 am, "Lawrence Lim" wrote: Hi, I just installed tomcat 8.5.23. I am having problems deploying web apps via manager. To reproduce: 1. Login to tomcat manager 2. Go to " WAR file to deploy" 3. Pick a war file Error message: FAIL - File upload failed, no file Workaround: Copy war file to the tomcat webapps directory I also tried using localhost:8080, same result. So, it's not some weird networking constraint. Lawrence Lim Software Developer - ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta T5J 0H3 enbridge.com Integrity. Safety. Respect. Probably directory permissions. Where did you extract tomcat and what are the permissions on the directory you are uploading to? Anything in tomcat log file? What happens if you manually try to copy file to the target directory as the user tomcat is running under?
RE: [External] RE: Tomcat 8.5.23
I installed tomcat via untar, something tar -zxf apache-tomcat-8.5.23.tar.gz.
I am running Java 8 and no security manager I know of.
I already did a chmod 777 in the tomcat directory.
Regards,
Lawrence Lim
Software Developer
—
ENBRIDGE
TEL: 780-969-6208
10175 101 St NW, Edmonton, Alberta T5J 0H3
enbridge.com
Integrity. Safety. Respect.
-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Thursday, February 22, 2018 11:45 PM
To: Tomcat Users List
Subject: [External] RE: Tomcat 8.5.23
Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim
:
>Red Hat Enterprise Linux Server release 6.9 (Santiago)
How did you install tomcat?
Are you running tomcat with some kind of security manager enabled (Java or
system wide)?
Can the tomcat user (running the process) write to the filesystem?
Regards,
Felix
>
>Yes. I did check the logs. It does not log anything when I deploy. But,
>it logs something when I undeploy.
>
>Lawrence Lim
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW, Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>-Original Message-
>From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
>Sent: Thursday, February 15, 2018 10:58 AM
>To: users@tomcat.apache.org
>Subject: [External] Re: Tomcat 8.5.23
>
>Which operating system?
>Did you check the logs?
>
>Sent using OWA for iPhone
>
>From: Lawrence Lim
>Sent: Thursday, February 15, 2018 11:09:54 PM
>To: users@tomcat.apache.org
>Subject: Tomcat 8.5.23
>
>Hi,
>
>
>
>I just installed tomcat 8.5.23. I am having problems deploying web apps
>via manager. To reproduce:
>
>
>
>1. Login to tomcat manager
>
>
>
>2. Go to " WAR file to deploy"
>
>
>
>3. Pick a war file
>
>
>
>
>
>Error message: FAIL - File upload failed, no file
>
>
>
>
>
>Workaround: Copy war file to the tomcat webapps directory
>
>
>
>
>
>I also tried using localhost:8080, same result. So, it's not some weird
>networking constraint.
>
>
>Lawrence Lim
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW, Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>::DISCLAIMER::
>___
>_
>Confidentiality Notice from Dixons Carphone plc (registered in England
>& Wales No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons
>Carphone"). The information contained in this e-mail and any
>attachments may be legally privileged, proprietary and/or confidential.
>If you received this e-mail in error, please notify the sender by
>return, permanently delete the e-mail and destroy all hard copies
>immediately. No warranty is made as to the completeness or accuracy of
>the information contained in this e-mail. Opinions, conclusions and
>statements of intent in this e-mail are those of the sender and will
>not bind any Dixons Carphone group company (Dixons Carphone Group)
>unless confirmed by an authorised representative independently of this
>e-mail. We do not accept responsibility for viruses; you must scan for
>these. E-mails sent to and from Dixons Carphone Group are routinely
>monitored for record keeping, quality control, training purposes, to
>ensure regulatory compliance and to prevent viruses and unauthorised
>use of our computer systems. The Carphone Warehouse Limited (registered
>in England & Wales No.02142673) is a member of the Dixons Carphone
>Group and is authorised and regulated by the Financial Conduct
>Authority.
>___
>_
>
>-
>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: Tomcat 8.5.23
Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim
:
>Red Hat Enterprise Linux Server release 6.9 (Santiago)
How did you install tomcat?
Are you running tomcat with some kind of security manager enabled (Java or
system wide)?
Can the tomcat user (running the process) write to the filesystem?
Regards,
Felix
>
>Yes. I did check the logs. It does not log anything when I deploy. But,
>it logs something when I undeploy.
>
>Lawrence Lim
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW, Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>-Original Message-
>From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
>Sent: Thursday, February 15, 2018 10:58 AM
>To: users@tomcat.apache.org
>Subject: [External] Re: Tomcat 8.5.23
>
>Which operating system?
>Did you check the logs?
>
>Sent using OWA for iPhone
>
>From: Lawrence Lim
>Sent: Thursday, February 15, 2018 11:09:54 PM
>To: users@tomcat.apache.org
>Subject: Tomcat 8.5.23
>
>Hi,
>
>
>
>I just installed tomcat 8.5.23. I am having problems deploying web apps
>via manager. To reproduce:
>
>
>
>1. Login to tomcat manager
>
>
>
>2. Go to " WAR file to deploy"
>
>
>
>3. Pick a war file
>
>
>
>
>
>Error message: FAIL - File upload failed, no file
>
>
>
>
>
>Workaround: Copy war file to the tomcat webapps directory
>
>
>
>
>
>I also tried using localhost:8080, same result. So, it's not some weird
>networking constraint.
>
>
>Lawrence Lim
>Software Developer
>-
>
>ENBRIDGE
>TEL: 780-969-6208
>10175 101 St NW, Edmonton, Alberta T5J 0H3
>
>enbridge.com
>Integrity. Safety. Respect.
>
>::DISCLAIMER::
>
>Confidentiality Notice from Dixons Carphone plc (registered in England
>& Wales No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons
>Carphone"). The information contained in this e-mail and any
>attachments may be legally privileged, proprietary and/or confidential.
>If you received this e-mail in error, please notify the sender by
>return, permanently delete the e-mail and destroy all hard copies
>immediately. No warranty is made as to the completeness or accuracy of
>the information contained in this e-mail. Opinions, conclusions and
>statements of intent in this e-mail are those of the sender and will
>not bind any Dixons Carphone group company (Dixons Carphone Group)
>unless confirmed by an authorised representative independently of this
>e-mail. We do not accept responsibility for viruses; you must scan for
>these. E-mails sent to and from Dixons Carphone Group are routinely
>monitored for record keeping, quality control, training purposes, to
>ensure regulatory compliance and to prevent viruses and unauthorised
>use of our computer systems. The Carphone Warehouse Limited (registered
>in England & Wales No.02142673) is a member of the Dixons Carphone
>Group and is authorised and regulated by the Financial Conduct
>Authority.
>
>
>-
>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: [E] RE: Tomcat 8.5.23
I was just suggesting that you check to make sure it's set, since it would
not deploy.
On Fri, Feb 16, 2018 at 2:32 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Margaret,
>
> On 2/15/18 10:46 PM, Bauer, Margaret M (Peggy) wrote:
> > I am not using 8.5, but in older tomcat you must set the below in
> > the server.xml
> >
> > > autoDeploy="true">
>
> That is the default configuration. So... what is your suggestion exactly
> ?
>
> - -chris
>
> > On Thu, Feb 15, 2018 at 1:25 PM, Lawrence Lim
> > wrote:
> >
> >> Red Hat Enterprise Linux Server release 6.9 (Santiago)
> >>
> >> Yes. I did check the logs. It does not log anything when I
> >> deploy. But, it logs something when I undeploy.
> >>
> >> Lawrence Lim Software Developer -
> >>
> >> ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta
> >> T5J 0H3
> >>
> >> enbridge.com Integrity. Safety. Respect.
> >>
> >> -Original Message- From: Satish Chhatpar 02
> >> [mailto:chhatp...@cpwplc.com] Sent: Thursday, February 15, 2018
> >> 10:58 AM To: users@tomcat.apache.org Subject: [External] Re:
> >> Tomcat 8.5.23
> >>
> >> Which operating system? Did you check the logs?
> >>
> >> Sent using OWA for iPhone From:
> >> Lawrence Lim Sent: Thursday, February
> >> 15, 2018 11:09:54 PM To: users@tomcat.apache.org Subject: Tomcat
> >> 8.5.23
> >>
> >> Hi,
> >>
> >>
> >>
> >> I just installed tomcat 8.5.23. I am having problems deploying
> >> web apps via manager. To reproduce:
> >>
> >>
> >>
> >> 1. Login to tomcat manager
> >>
> >>
> >>
> >> 2. Go to " WAR file to deploy"
> >>
> >>
> >>
> >> 3. Pick a war file
> >>
> >>
> >>
> >>
> >>
> >> Error message: FAIL - File upload failed, no file
> >>
> >>
> >>
> >>
> >>
> >> Workaround: Copy war file to the tomcat webapps directory
> >>
> >>
> >>
> >>
> >>
> >> I also tried using localhost:8080, same result. So, it's not some
> >> weird networking constraint.
> >>
> >>
> >> Lawrence Lim Software Developer -
> >>
> >> ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta
> >> T5J 0H3
> >>
> >> enbridge.com Integrity. Safety. Respect.
> >>
> >> ::DISCLAIMER::
> >>
> >>
> >> Confidentiality Notice from Dixons Carphone plc (registered in
> >> England & Wales No.07105905) of 1 Portal Way, London, W3 6RS
> >> ("Dixons Carphone"). The information contained in this e-mail and
> >> any attachments may be legally privileged, proprietary and/or
> >> confidential. If you received this e-mail in error, please notify
> >> the sender by return, permanently delete the e-mail and destroy
> >> all hard copies immediately. No warranty is made as to the
> >> completeness or accuracy of the information contained in this
> >> e-mail. Opinions, conclusions and statements of intent in this
> >> e-mail are those of the sender and will not bind any Dixons
> >> Carphone group company (Dixons Carphone Group) unless confirmed
> >> by an authorised representative independently of this e-mail. We
> >> do not accept responsibility for viruses; you must scan for
> >> these. E-mails sent to and from Dixons Carphone Group are
> >> routinely monitored for record keeping, quality control, training
> >> purposes, to ensure regulatory compliance and to prevent viruses
> >> and unauthorised use of our computer systems. The Carphone
> >> Warehouse Limited (registered in England & Wales No.02142673) is
> >> a member of the Dixons Carphone Group and is authorised and
> >> regulated by the Financial Conduct Authority.
> >>
> >>
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> &
Re: [E] RE: Tomcat 8.5.23
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Margaret,
On 2/15/18 10:46 PM, Bauer, Margaret M (Peggy) wrote:
> I am not using 8.5, but in older tomcat you must set the below in
> the server.xml
>
> autoDeploy="true">
That is the default configuration. So... what is your suggestion exactly
?
- -chris
> On Thu, Feb 15, 2018 at 1:25 PM, Lawrence Lim
> wrote:
>
>> Red Hat Enterprise Linux Server release 6.9 (Santiago)
>>
>> Yes. I did check the logs. It does not log anything when I
>> deploy. But, it logs something when I undeploy.
>>
>> Lawrence Lim Software Developer -
>>
>> ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta
>> T5J 0H3
>>
>> enbridge.com Integrity. Safety. Respect.
>>
>> -Original Message- From: Satish Chhatpar 02
>> [mailto:chhatp...@cpwplc.com] Sent: Thursday, February 15, 2018
>> 10:58 AM To: users@tomcat.apache.org Subject: [External] Re:
>> Tomcat 8.5.23
>>
>> Which operating system? Did you check the logs?
>>
>> Sent using OWA for iPhone From:
>> Lawrence Lim Sent: Thursday, February
>> 15, 2018 11:09:54 PM To: users@tomcat.apache.org Subject: Tomcat
>> 8.5.23
>>
>> Hi,
>>
>>
>>
>> I just installed tomcat 8.5.23. I am having problems deploying
>> web apps via manager. To reproduce:
>>
>>
>>
>> 1. Login to tomcat manager
>>
>>
>>
>> 2. Go to " WAR file to deploy"
>>
>>
>>
>> 3. Pick a war file
>>
>>
>>
>>
>>
>> Error message: FAIL - File upload failed, no file
>>
>>
>>
>>
>>
>> Workaround: Copy war file to the tomcat webapps directory
>>
>>
>>
>>
>>
>> I also tried using localhost:8080, same result. So, it's not some
>> weird networking constraint.
>>
>>
>> Lawrence Lim Software Developer -
>>
>> ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta
>> T5J 0H3
>>
>> enbridge.com Integrity. Safety. Respect.
>>
>> ::DISCLAIMER::
>>
>>
>> Confidentiality Notice from Dixons Carphone plc (registered in
>> England & Wales No.07105905) of 1 Portal Way, London, W3 6RS
>> ("Dixons Carphone"). The information contained in this e-mail and
>> any attachments may be legally privileged, proprietary and/or
>> confidential. If you received this e-mail in error, please notify
>> the sender by return, permanently delete the e-mail and destroy
>> all hard copies immediately. No warranty is made as to the
>> completeness or accuracy of the information contained in this
>> e-mail. Opinions, conclusions and statements of intent in this
>> e-mail are those of the sender and will not bind any Dixons
>> Carphone group company (Dixons Carphone Group) unless confirmed
>> by an authorised representative independently of this e-mail. We
>> do not accept responsibility for viruses; you must scan for
>> these. E-mails sent to and from Dixons Carphone Group are
>> routinely monitored for record keeping, quality control, training
>> purposes, to ensure regulatory compliance and to prevent viruses
>> and unauthorised use of our computer systems. The Carphone
>> Warehouse Limited (registered in England & Wales No.02142673) is
>> a member of the Dixons Carphone Group and is authorised and
>> regulated by the Financial Conduct Authority.
>>
>>
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqHMcsACgkQHPApP6U8
pFgjpRAAuawUIvJ6cBsStytSyqy9dRCbLM6XcYO72w2JAe6OriGwzSmPlFgJtGnD
QuNwSgyZc0g7ePG6fpg6+QCQ6aA3wOEeBMVbUH0oj+KssdhyizNf/j1sGEEJ/Kwd
MPoCXZX0ekZWRqCNlzzs6j4czunSbi6rm2AGP7UZGW3HqCV6hYzc5qvLhrZf2ddN
7bsRlp9rqmdCuLr3etzJ5pXE1ewbcHQGc83hKvGNYzgBUkTkYfImYU1nJQjcae03
BquueYMJA4clfh6NFiknAAhOb8Ok5Sl+CKUPnmsxwJz1s/41plVNeMuWFTbe7gy2
7OhLXBSSkb+rUloNBmWD2ACjL+/yb7KohPTCH0zK7xQQjYqenS4+MPgT8XH/hWJ2
na6+yEqqFxEE8XuvW5EuZSGwYp5yjnLKfZuCz9tvibs4pCFSiARpF1ChcCCmtSZN
TDOrQEU2qoplfM8Vn6SX4VGi5nBq82AKP9UxRsgrC7gRl4MdEVBFLBlzgsHmSAA+
hE9gAnsLx5TI4q3ktSoMDwRMy92rAJrAOnmKyaD4RrWag2sTi9oV845fyI15V0JA
DV0dsjf9YQvQVDnDamyaWlNc2iVeK9YsxHquKGWSff794oHx5Na82SSWOEH7r5cO
mvsc9aTR5Z7rXfXJfbsJRBYHOWWCw9WrLds86WseShdl6Ps0mw4=
=p7Hf
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [E] RE: Tomcat 8.5.23
I am not using 8.5, but in older tomcat you must set the below in the
server.xml
On Thu, Feb 15, 2018 at 1:25 PM, Lawrence Lim
wrote:
> Red Hat Enterprise Linux Server release 6.9 (Santiago)
>
> Yes. I did check the logs. It does not log anything when I deploy. But, it
> logs something when I undeploy.
>
> Lawrence Lim
> Software Developer
> -
>
> ENBRIDGE
> TEL: 780-969-6208
> 10175 101 St NW, Edmonton, Alberta T5J 0H3
>
> enbridge.com
> Integrity. Safety. Respect.
>
> -Original Message-
> From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
> Sent: Thursday, February 15, 2018 10:58 AM
> To: users@tomcat.apache.org
> Subject: [External] Re: Tomcat 8.5.23
>
> Which operating system?
> Did you check the logs?
>
> Sent using OWA for iPhone
>
> From: Lawrence Lim
> Sent: Thursday, February 15, 2018 11:09:54 PM
> To: users@tomcat.apache.org
> Subject: Tomcat 8.5.23
>
> Hi,
>
>
>
> I just installed tomcat 8.5.23. I am having problems deploying web apps
> via manager. To reproduce:
>
>
>
> 1. Login to tomcat manager
>
>
>
> 2. Go to " WAR file to deploy"
>
>
>
> 3. Pick a war file
>
>
>
>
>
> Error message: FAIL - File upload failed, no file
>
>
>
>
>
> Workaround: Copy war file to the tomcat webapps directory
>
>
>
>
>
> I also tried using localhost:8080, same result. So, it's not some weird
> networking constraint.
>
>
> Lawrence Lim
> Software Developer
> -
>
> ENBRIDGE
> TEL: 780-969-6208
> 10175 101 St NW, Edmonton, Alberta T5J 0H3
>
> enbridge.com
> Integrity. Safety. Respect.
>
> ::DISCLAIMER::
>
>
> Confidentiality Notice from Dixons Carphone plc (registered in England &
> Wales No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons Carphone"). The
> information contained in this e-mail and any attachments may be legally
> privileged, proprietary and/or confidential. If you received this e-mail in
> error, please notify the sender by return, permanently delete the e-mail
> and destroy all hard copies immediately. No warranty is made as to the
> completeness or accuracy of the information contained in this e-mail.
> Opinions, conclusions and statements of intent in this e-mail are those of
> the sender and will not bind any Dixons Carphone group company (Dixons
> Carphone Group) unless confirmed by an authorised representative
> independently of this e-mail. We do not accept responsibility for viruses;
> you must scan for these. E-mails sent to and from Dixons Carphone Group are
> routinely monitored for record keeping, quality control, training purposes,
> to ensure regulatory compliance and to prevent viruses and unauthorised use
> of our computer systems. The Carphone Warehouse Limited (registered in
> England & Wales No.02142673) is a member of the Dixons Carphone Group and
> is authorised and regulated by the Financial Conduct Authority.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
*Peggy Bauer*
CAO Production Support
214-770-1782
RE: Tomcat 8.5.23
Red Hat Enterprise Linux Server release 6.9 (Santiago)
Yes. I did check the logs. It does not log anything when I deploy. But, it logs
something when I undeploy.
Lawrence Lim
Software Developer
-
ENBRIDGE
TEL: 780-969-6208
10175 101 St NW, Edmonton, Alberta T5J 0H3
enbridge.com
Integrity. Safety. Respect.
-Original Message-
From: Satish Chhatpar 02 [mailto:chhatp...@cpwplc.com]
Sent: Thursday, February 15, 2018 10:58 AM
To: users@tomcat.apache.org
Subject: [External] Re: Tomcat 8.5.23
Which operating system?
Did you check the logs?
Sent using OWA for iPhone
From: Lawrence Lim
Sent: Thursday, February 15, 2018 11:09:54 PM
To: users@tomcat.apache.org
Subject: Tomcat 8.5.23
Hi,
I just installed tomcat 8.5.23. I am having problems deploying web apps via
manager. To reproduce:
1. Login to tomcat manager
2. Go to " WAR file to deploy"
3. Pick a war file
Error message: FAIL - File upload failed, no file
Workaround: Copy war file to the tomcat webapps directory
I also tried using localhost:8080, same result. So, it's not some weird
networking constraint.
Lawrence Lim
Software Developer
-
ENBRIDGE
TEL: 780-969-6208
10175 101 St NW, Edmonton, Alberta T5J 0H3
enbridge.com
Integrity. Safety. Respect.
::DISCLAIMER::
Confidentiality Notice from Dixons Carphone plc (registered in England & Wales
No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons Carphone"). The
information contained in this e-mail and any attachments may be legally
privileged, proprietary and/or confidential. If you received this e-mail in
error, please notify the sender by return, permanently delete the e-mail and
destroy all hard copies immediately. No warranty is made as to the completeness
or accuracy of the information contained in this e-mail. Opinions, conclusions
and statements of intent in this e-mail are those of the sender and will not
bind any Dixons Carphone group company (Dixons Carphone Group) unless confirmed
by an authorised representative independently of this e-mail. We do not accept
responsibility for viruses; you must scan for these. E-mails sent to and from
Dixons Carphone Group are routinely monitored for record keeping, quality
control, training purposes, to ensure regulatory compliance and to prevent
viruses and unauthorised use of our computer systems. The Carphone Warehouse
Limited (registered in England & Wales No.02142673) is a member of the Dixons
Carphone Group and is authorised and regulated by the Financial Conduct
Authority.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.23
Which operating system?
Did you check the logs?
Sent using OWA for iPhone
From: Lawrence Lim
Sent: Thursday, February 15, 2018 11:09:54 PM
To: users@tomcat.apache.org
Subject: Tomcat 8.5.23
Hi,
I just installed tomcat 8.5.23. I am having problems deploying web apps via
manager. To reproduce:
1. Login to tomcat manager
2. Go to " WAR file to deploy"
3. Pick a war file
Error message: FAIL - File upload failed, no file
Workaround: Copy war file to the tomcat webapps directory
I also tried using localhost:8080, same result. So, it's not some weird
networking constraint.
Lawrence Lim
Software Developer
-
ENBRIDGE
TEL: 780-969-6208
10175 101 St NW, Edmonton, Alberta T5J 0H3
enbridge.com
Integrity. Safety. Respect.
::DISCLAIMER::
Confidentiality Notice from Dixons Carphone plc (registered in England & Wales
No.07105905) of 1 Portal Way, London, W3 6RS ("Dixons Carphone"). The
information contained in this e-mail and any attachments may be legally
privileged, proprietary and/or confidential. If you received this e-mail in
error, please notify the sender by return, permanently delete the e-mail and
destroy all hard copies immediately. No warranty is made as to the completeness
or accuracy of the information contained in this e-mail. Opinions, conclusions
and statements of intent in this e-mail are those of the sender and will not
bind any Dixons Carphone group company (Dixons Carphone Group) unless confirmed
by an authorised representative independently of this e-mail. We do not accept
responsibility for viruses; you must scan for these. E-mails sent to and from
Dixons Carphone Group are routinely monitored for record keeping, quality
control, training purposes, to ensure regulatory compliance and to prevent
viruses and unauthorised use of our computer systems. The Carphone Warehouse
Limited (registered in England & Wales No.02142673) is a member of the Dixons
Carphone Group and is authorised and regulated by the Financial Conduct
Authority.
Tomcat 8.5.23
Hi, I just installed tomcat 8.5.23. I am having problems deploying web apps via manager. To reproduce: 1. Login to tomcat manager 2. Go to " WAR file to deploy" 3. Pick a war file Error message: FAIL - File upload failed, no file Workaround: Copy war file to the tomcat webapps directory I also tried using localhost:8080, same result. So, it's not some weird networking constraint. Lawrence Lim Software Developer - ENBRIDGE TEL: 780-969-6208 10175 101 St NW, Edmonton, Alberta T5J 0H3 enbridge.com Integrity. Safety. Respect.
Re: Switch to in-memory key store in tomcat 8.5.23 fails application to load
On 15/02/18 07:52, Emil John wrote:
> Context
> ---
>
> Exact tomcat version, Operating Systems, other configurations-
>
> Current Tomcat version - 8.5.15
> Operating Systems - Windows/ Linux
> Upgrading to tomcat version - 8.5.23
> Application - Java Application.
>
> I have an application with tomcat, say fooapp. I also have a custom
> keystore type, say DKS (Java by default has the JKS keystore). During start
> of my application, it loads the DKS keystore to get the certificate for the
> application. This is done using the following changes in server.xml
>
> sslImplementationName="com.vmware.identity.tomcat.GKSAwareImpl"
> store="CERT_STORE"
> port="${bio-ssl-localhost.https.port}"
> protocol="com.vmware.identity.tomcat. GKSAwareHttp11NioProtocol"
> redirectPort="${bio-ssl-localhost.https.port}"
> scheme="https"
> secure="true"
> maxHttpHeaderSize="16384">
>
>
> Problem
> ---
>
> The new version of tomcat has a changed code that is causing my application
> from not able to load the GKS keystore.
>
> In Tomcat 8.5.15,
> getKeyManagers() method - if ks is not null, it simply proceeds further
> doing the ks.isKeyEntry() etc..
>
> In Tomcat 8.5.23,
> getKeyManagers() method - if ks is initialized as before and create a new
> reference -
> KeyStore ks = certificate.getCertificateKeystore();
> KeyStore ksUsed = ks;
>
> After the below code, the ksUsed is getting back to JKS and fails to load
> my custom keystore type "GKS"
>
> // Switch to in-memory key store String provider =
> certificate.getCertificateKeystoreProvider(); if (provider == null) {
> ksUsed = KeyStore.getInstance(certificate.getCertificateKeystoreType()); }
> else { ksUsed =
> KeyStore.getInstance(certificate.getCertificateKeystoreType(), provider); }
> ksUsed.load(null, null); --> throws unimplmented method
>
> I am setting the provider type properly in java.security which is also used
> while loading the application.
>
> Has anybody faced similar problem?
You should try 8.5.24 or later since there was a further change in
8.5.24 in this area.
You might want to talk to VMware support about the unimplemented method
as I'd expect any custom KeyStore to support that usage.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Switch to in-memory key store in tomcat 8.5.23 fails application to load
Emil,
On 15 Feb 2018, 8:52 PM +1300, Emil John , wrote:
> Context
> ---
>
> Exact tomcat version, Operating Systems, other configurations-
>
> Current Tomcat version - 8.5.15
> Operating Systems - Windows/ Linux
> Upgrading to tomcat version - 8.5.23
> Application - Java Application.
>
> I have an application with tomcat, say fooapp. I also have a custom
> keystore type, say DKS (Java by default has the JKS keystore). During start
> of my application, it loads the DKS keystore to get the certificate for the
> application. This is done using the following changes in server.xml
>
> sslImplementationName="com.vmware.identity.tomcat.GKSAwareImpl"
> store="CERT_STORE"
> port="${bio-ssl-localhost.https.port}"
> protocol="com.vmware.identity.tomcat. GKSAwareHttp11NioProtocol"
> redirectPort="${bio-ssl-localhost.https.port}"
> scheme="https"
> secure="true"
> maxHttpHeaderSize="16384"
>
>
> Problem
> ---
>
> The new version of tomcat has a changed code that is causing my application
> from not able to load the GKS keystore.
>
> In Tomcat 8.5.15,
> getKeyManagers() method - if ks is not null, it simply proceeds further
> doing the ks.isKeyEntry() etc..
>
> In Tomcat 8.5.23,
> getKeyManagers() method - if ks is initialized as before and create a new
> reference -
> KeyStore ks = certificate.getCertificateKeystore();
> KeyStore ksUsed = ks;
>
> After the below code, the ksUsed is getting back to JKS and fails to load
> my custom keystore type "GKS"
>
> // Switch to in-memory key store String provider =
> certificate.getCertificateKeystoreProvider(); if (provider == null) {
> ksUsed = KeyStore.getInstance(certificate.getCertificateKeystoreType()); }
> else { ksUsed =
> KeyStore.getInstance(certificate.getCertificateKeystoreType(), provider); }
> ksUsed.load(null, null); --> throws unimplmented method
>
> I am setting the provider type properly in java.security which is also used
> while loading the application.
>
> Has anybody faced similar problem?
I had a similar problem – not quite the same but close enough. I ended up
creating another key store type that wraps around my existing types. See my
threads here http://markmail.org/message/5vus3jpsp5secm44
Cheers,
Ing
>
> Thanks,
> Emil
Switch to in-memory key store in tomcat 8.5.23 fails application to load
Context --- Exact tomcat version, Operating Systems, other configurations- Current Tomcat version - 8.5.15 Operating Systems - Windows/ Linux Upgrading to tomcat version - 8.5.23 Application - Java Application. I have an application with tomcat, say fooapp. I also have a custom keystore type, say DKS (Java by default has the JKS keystore). During start of my application, it loads the DKS keystore to get the certificate for the application. This is done using the following changes in server.xml throws unimplmented method I am setting the provider type properly in java.security which is also used while loading the application. Has anybody faced similar problem? Thanks, Emil
Re: Trouble with TLS/SSL and Tomcat 8.5.23
On 23 November 2017 at 17:20, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Richard, > > On 11/23/17 8:28 AM, Richard Tearle wrote: >> Yes I read through that thread, but we don't really like Java key >> stores, and I don't think the work around would work for us. > > Java keystores are ... awful. > >> Instead, I did what perhaps I should have done a while ago (on >> version 8.0.x), and built Tomcat Native libraries, deployed, and >> changed the certificate references in the connector to use our .PEM >> files (which the PKCS12 files are built from), and fingers crossed, >> its looking OK at the moment. > > So are you using the APR connector, then? > > You do have some other options: > > 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of > keystores. > > 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for > everything, simply because they are so easy to work with. > > 3. JSSE+OpenSSL with PEM-encoded DER files. > > Option #3 will get you the performance of OpenSSL's crypto but without > using the APR connector (which isn't quite as efficient as the > pure-Java NIO connector). Java's crypto seems to be hobbled for some > reason... some kind of mistake in the native-optimization that ends up > falling-back to pure-Java crypto which ... simply isn't fast enough > for real-world workloads). > > I think the APR connector is likely to disappear with the next major > release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination > is becoming more mature and offers better performance and scalability. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8 > pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T > hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i > tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6 > IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk > DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg > l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC > EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS > lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0 > 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I > jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP > t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM= > =bf9o > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Hi I think Option #1 was what I was trying to achieve originally. I'll take a look at option #3 tomorrow. Thanks for the heads up Richard. -- This email is sent on behalf of Northgate Public Services (UK) Limited and its associated companies including Rave Technologies (India) Pvt Limited (together "Northgate Public Services") and is strictly confidential and intended solely for the addressee(s). If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully; (ii) contact Northgate Public Services immediately on +44(0)1442 768445 quoting the name of the sender and the addressee then delete it from your system. Northgate Public Services has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. You should scan attachments (if any) for viruses. Northgate Public Services (UK) Limited, registered in England and Wales under number 00968498 with a registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW. Rave Technologies (India) Pvt Limited, registered in India under number 117068 with a registered address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with TLS/SSL and Tomcat 8.5.23
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Richard, On 11/23/17 8:28 AM, Richard Tearle wrote: > Yes I read through that thread, but we don't really like Java key > stores, and I don't think the work around would work for us. Java keystores are ... awful. > Instead, I did what perhaps I should have done a while ago (on > version 8.0.x), and built Tomcat Native libraries, deployed, and > changed the certificate references in the connector to use our .PEM > files (which the PKCS12 files are built from), and fingers crossed, > its looking OK at the moment. So are you using the APR connector, then? You do have some other options: 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of keystores. 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for everything, simply because they are so easy to work with. 3. JSSE+OpenSSL with PEM-encoded DER files. Option #3 will get you the performance of OpenSSL's crypto but without using the APR connector (which isn't quite as efficient as the pure-Java NIO connector). Java's crypto seems to be hobbled for some reason... some kind of mistake in the native-optimization that ends up falling-back to pure-Java crypto which ... simply isn't fast enough for real-world workloads). I think the APR connector is likely to disappear with the next major release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination is becoming more mature and offers better performance and scalability. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8 pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6 IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM= =bf9o -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with TLS/SSL and Tomcat 8.5.23
On 23 November 2017 at 05:33, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/22/17 8:40 AM, Richard Tearle wrote:
>> Hello
>>
>> Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java
>> 1.8.0_152 (with jce) Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to
>> 8.5.23, but when trying to get TLS/SSL working on a connector I get
>> the following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end
>> point associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:115)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
> seEndpoint.java:86)
>> at
>> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:9
> 82)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:245)
>>
>>
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:66)
>>
>>
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> 97)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.ja
> va:549)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
> :875)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
>>
>>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty at
>> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200)
>>
>>
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
> java:130)
>>
>>
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:
> 368)
>> at
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
> a:292)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstrac
> tJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not
>> exact issues, and going back to 8.5.4 "solved" the issue. So I did
>> this as a quick test, so at least I could see that our
>> configuration changes where correct, and yes the application ran ok
>> with Tomcat 8.5.4. The connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> server="Apache" maxPostSize="10"> > certificateVerification="none" sslProtocol="TLSv1.2"
>> protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12" truststorePassword="${truststore.pass}"
>> honorCipherOrder="true"
>> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AE
> S_256_GCM_SHA
Re: Trouble with TLS/SSL and Tomcat 8.5.23
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Richard,
On 11/22/17 8:40 AM, Richard Tearle wrote:
> Hello
>
> Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java
> 1.8.0_152 (with jce) Running in Docker Container
>
> I'm upgrading our applications from Apache Tomcat 8.0.47 to
> 8.5.23, but when trying to get TLS/SSL working on a connector I get
> the following error:
>
> 22-Nov-2017 11:52:46.098 SEVERE [main]
> org.apache.coyote.AbstractProtocol.init Failed to initialize end
> point associated with ProtocolHandler ["https-jsse-nio2-18443"]
> java.lang.IllegalArgumentException:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:115)
>
>
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
seEndpoint.java:86)
> at
> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>
>
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:9
82)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
int.java:245)
>
>
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
tocol.java:66)
>
>
at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
97)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>
>
at
org.apache.catalina.core.StandardService.initInternal(StandardService.ja
va:549)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>
>
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
:875)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>
>
at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
ava:62)
>
>
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty at
> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
200)
>
>
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
java:130)
>
>
at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:
368)
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
a:292)
>
>
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstrac
tJsseEndpoint.java:113)
> ... 20 more
>
> I've changed the connector configuration to use
> SSLHostConfig/Certificate, but our certificate generation process
> (self signed certificates) has remained the same. I did a quick
> internet search, and saw that other people had similar, but not
> exact issues, and going back to 8.5.4 "solved" the issue. So I did
> this as a quick test, so at least I could see that our
> configuration changes where correct, and yes the application ran ok
> with Tomcat 8.5.4. The connector configuration is:
>
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> server="Apache" maxPostSize="10"> certificateVerification="none" sslProtocol="TLSv1.2"
> protocols="TLSv1.2"
> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
> truststoreType="PKCS12" truststorePassword="${truststore.pass}"
> honorCipherOrder="true"
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AE
S_256_GCM_SHA384,
>
>
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_S
HA384,
>
>
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM
_SHA256,
>
>
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_S
HA256,
>
>
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC
_SHA384,
>
>
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SH
A,
>
>
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_W
Re: Trouble with TLS/SSL and Tomcat 8.5.23
Peter
On 22 November 2017 at 15:08, Peter Kreuser wrote:
>
>
>
>
> Richard,
>
>
>
>
>
>> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
>> Von: "Richard Tearle"
>> mailto:richard.tea...@northgateps.com]>
>> An: users@tomcat.apache.org[mailto:users@tomcat.apache.org]
>> Betreff: Trouble with TLS/SSL and Tomcat 8.5.23
>> Hello
>>
>> Apache Tomcat 8.5.23
>> Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
>> Java 1.8.0_152 (with jce)
>> Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
>> but when trying to get TLS/SSL working on a connector I get the
>> following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
>> associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
>> at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
>> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
>> at org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty
>> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
>> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
>> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
>> at
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not exact
>> issues, and going back to 8.5.4 "solved" the issue. So I did this as a
>> quick test, so at least I could see that our configuration changes
>> where correct, and yes the application ran ok with Tomcat 8.5.4. The
>> connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https"
>> secure="true" server="Apache" maxPostSize="10">
>> > sslProtocol="TLSv1.2" protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12"
>> truststorePassword="${truststore.pass}" honorCipherOrder="true"
>
> The error message says that either the file simply is not there or the cert
> that you expect is not in the
Aw: Trouble with TLS/SSL and Tomcat 8.5.23
Richard,
> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
> Von: "Richard Tearle"
> mailto:richard.tea...@northgateps.com]>
> An: users@tomcat.apache.org[mailto:users@tomcat.apache.org]
> Betreff: Trouble with TLS/SSL and Tomcat 8.5.23
> Hello
>
> Apache Tomcat 8.5.23
> Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
> Java 1.8.0_152 (with jce)
> Running in Docker Container
>
> I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
> but when trying to get TLS/SSL working on a connector I get the
> following error:
>
> 22-Nov-2017 11:52:46.098 SEVERE [main]
> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
> associated with ProtocolHandler ["https-jsse-nio2-18443"]
> java.lang.IllegalArgumentException:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
> at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
> at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> ... 20 more
>
> I've changed the connector configuration to use
> SSLHostConfig/Certificate, but our certificate generation process
> (self signed certificates) has remained the same. I did a quick
> internet search, and saw that other people had similar, but not exact
> issues, and going back to 8.5.4 "solved" the issue. So I did this as a
> quick test, so at least I could see that our configuration changes
> where correct, and yes the application ran ok with Tomcat 8.5.4. The
> connector configuration is:
>
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" server="Apache" maxPostSize="10">
> sslProtocol="TLSv1.2" protocols="TLSv1.2"
> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
> truststoreType="PKCS12"
> truststorePassword="${truststore.pass}" honorCipherOrder="true"
The error message says that either the file simply is not there or the cert
that you expect is not in the keystore, maybe even empty...
Peter
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
>
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
>
> TLS_ECDHE_RSA_WITH_AES_256_
Trouble with TLS/SSL and Tomcat 8.5.23
Hello Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java 1.8.0_152 (with jce) Running in Docker Container I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23, but when trying to get TLS/SSL working on a connector I get the following error: 22-Nov-2017 11:52:46.098 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler ["https-jsse-nio2-18443"] java.lang.IllegalArgumentException: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86) at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982) at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66) at org.apache.catalina.connector.Connector.initInternal(Connector.java:997) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:549) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107) at org.apache.catalina.startup.Catalina.load(Catalina.java:621) at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494) Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) at java.security.cert.PKIXParameters.(PKIXParameters.java:157) at java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130) at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368) at org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113) ... 20 more I've changed the connector configuration to use SSLHostConfig/Certificate, but our certificate generation process (self signed certificates) has remained the same. I did a quick internet search, and saw that other people had similar, but not exact issues, and going back to 8.5.4 "solved" the issue. So I did this as a quick test, so at least I could see that our configuration changes where correct, and yes the application ran ok with Tomcat 8.5.4. The connector configuration is: Setting javax.net.debug=all in CATALINA_OPTS and viewing the resultant logging, seems to indicate that the certificate is being loaded, but not the trust store, with the only truststore loaded coming from: /opt/jre1.8.0_152/lib/security/cacerts Best Regards Richard -- This email is sent on behalf of Northgate Public Services (UK) Limited and its associated companies including Rave Technologies (India) Pvt Limited (together "Northgate Public Services") and is strictly confidential and intended solely for the addressee(s). If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully; (ii) contact Northgate Public Services immediately on +44(0)1442 768445 quoting the name of the sender and the addressee then delete it from your system. Northgate Public Services has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. You should scan attachments (if any) for viruses. Northgate Public Services (UK) Limited, registered in England and Wales under number 00968498 with a registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW. Rave Technologies (India) Pvt Limited, registered in Indi
Re: Fw: TomCat 8.5.23 application not responding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darin, On 11/3/17 5:17 PM, dbol...@dsginc.biz wrote: > From: Christopher Schultz To: > users@tomcat.apache.org Date: 11/02/2017 02:28 PM Subject: > Re: TomCat 8.5.23 application not responding > > > > Darin, > > On 11/2/17 12:55 PM, dbol...@dsginc.biz wrote: >> I have a TomCat 8.5.23 service running on a Windows 2008 R2. It >> is currently running a third party web commerce application. It >> will run great until randomly one day the application will stop >> responding. When you try to go to the application URL it sits >> and spins. I look at the catalina log and found the below errors >> at the time it stop responding. Is this a tomcat configuration >> issue or application related. > >> I see three specific warning/severe messages in Tomcat. > >> Error one: 02-Nov-2017 10:03:23.787 WARNING >> [http-nio-9080-exec-402] >> com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getForComponent >> >> Unable to find component with ID searchPattern in view. > >> Then right after there is a severe message error 2: > >> 02-Nov-2017 10:03:23.896 SEVERE [http-nio-9080-exec-455] >> org.restlet.engine.http.adapter.ServerAdapter.commit An >> exception occured writing the response entity >> org.apache.catalina.connector.ClientAbortException: >> java.io.IOException: An established connection was aborted by >> the software in your host machine > >> Then the warning messages constant all the way down until this >> all the way down until we had to reboot the service because of >> no response. > >> 02-Nov-2017 10:03:23.896 WARNING [http-nio-9080-exec-455] >> org.restlet.engine.http.HttpServerHelper.handle Error while >> handling an HTTP server call: 02-Nov-2017 10:03:23.896 INFO >> [http-nio-9080-exec-455] >> org.restlet.engine.http.HttpServerHelper.handle Error while >> handling an HTTP server call java.lang.IllegalStateException: >> Cannot call sendError() after the response has been committed > > Can you take some thread dumps to show what the Tomcat threads are > doing? One thread dump will probably be very long, but go ahead > and post the whole thing to the list. > > -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I have been unable to post the thread dump because of size no > matter how much I send under the 1 MB rule. Is there another way I > can send it to you. Thanks. > > > I do see a lot of Blocked messages, see example. I was not able to > post the whole dump. > > > "http-nio-9080-exec-305" #3888 daemon prio=5 os_prio=0 > tid=0x1f445000 nid=0x230 waiting for monitor entry > [0x4341d000] java.lang.Thread.State: BLOCKED (on object > monitor) at > com.mincron.api.restlet.dm.ProductDM.getCategoryItemList(Unknown > Source) - waiting to lock <0x000696269dc0> (a java.lang.Class > for com.mincron.api.restlet.dm.ProductDM) at > com.mincron.api.restlet.resource.CategoryItemListResource.retrieve(Unk nown > Source) Your own code is blocking on something -- whatever a ProductDM is. If you recompile your code with "debug" symbols enabled, you can see line numbers and you'll be able to find out exactly what's going on. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln904YACgkQHPApP6U8 pFhQhQ//ep1OPpEP8GSCLKRxwO4Pd+cRc0AN+pj769dzMmEcLRIGxMRHNm0Em8Ig GvmoLkoJ2wNsqZ7IDi3vGKj1unSNZ1RJ8IV7qtCf6AOoas1OELE6SY+Lwkmpa9xl wz7iZLxuygcdLB6OsdQP1CzndJUUvBR9X2be+oPyEvKfHXciTsK6+ztownIPOxa1 dYWEPs9ruqFfxw8e+QnoT8ZGsETZcxWVnRVnaWMSxtvR2uLIrsC6p/JE19gVr1YL rXIHJdbUVmx+C0ewOXAC7QzsBIV7DELcn8kczRmvPWaX+o0J8/ushCibdRqWlSn2 MzctyIgFiog68wyxBbJBmjsxMKk6O0OtVZHOtZKEiRRw5el8epC8cVNpefR6fAha FFmV/ErkEQXzgqGyHOJIQpNiJxRJvzjphdETqWumzUT9E+ZiPfKhNdcwPf7Nmn5C EApGDgGBAndh2ZpNdKQU69q/kmwCWHQxQ0XHXfQyJr0/9vU7B+4ahFbCprTz8jbB /mLmIpcIoJ40gYONRbiLONAB22ocjsAXdNY/MoP6w/5DogYcsAUAv/Xt7Xvcy8ds iaul2Ige1qlyVGwNYiIbBfDoRUsHypDWQ6tk3bFs3NYh1oHwJ3ooNEK4SDnZE4Ds Ky9auBMznXit4MRsN02N8r+C8H4vqomP9/JlmtWJgYidOidoOKk= =egb5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fw: TomCat 8.5.23 application not responding
From: Christopher Schultz To: users@tomcat.apache.org Date: 11/02/2017 02:28 PM Subject:Re: TomCat 8.5.23 application not responding -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darin, On 11/2/17 12:55 PM, dbol...@dsginc.biz wrote: > I have a TomCat 8.5.23 service running on a Windows 2008 R2. It is > currently running a third party web commerce application. It will > run great until randomly one day the application will stop > responding. When you try to go to the application URL it sits and > spins. I look at the catalina log and found the below errors at > the time it stop responding. Is this a tomcat configuration issue > or application related. > > I see three specific warning/severe messages in Tomcat. > > Error one: 02-Nov-2017 10:03:23.787 WARNING > [http-nio-9080-exec-402] > com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getForComponent > Unable to find component with ID searchPattern in view. > > Then right after there is a severe message error 2: > > 02-Nov-2017 10:03:23.896 SEVERE [http-nio-9080-exec-455] > org.restlet.engine.http.adapter.ServerAdapter.commit An exception > occured writing the response entity > org.apache.catalina.connector.ClientAbortException: > java.io.IOException: An established connection was aborted by the > software in your host machine > > Then the warning messages constant all the way down until this all > the way down until we had to reboot the service because of no > response. > > 02-Nov-2017 10:03:23.896 WARNING [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call: 02-Nov-2017 10:03:23.896 INFO > [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call java.lang.IllegalStateException: > Cannot call sendError() after the response has been committed Can you take some thread dumps to show what the Tomcat threads are doing? One thread dump will probably be very long, but go ahead and post the whole thing to the list. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln7ckIdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh8og/8CataalwbNgVBl+uK f3q1W5JEOZbXBR2dA3UuR/mtZxHa6azH7UMSiydRpcRVoRvP7z0aeDyGoW/u70MT 23RlkNFDVG5HP6Z6AIBKrDisQDwHYRM9iq2o3vPYW56mgDLC56yxUKnKUATHGpgB MYk0vzicWawt1+zF/GE7qshTtubt5HgqmFFckhFPWWTRqsvkiyYIbkq9o6iUNHZZ MMPwe9ppeKOVew2c5csqLaSS9MUdbYerEblvho7WfQSW8YjtL6UO2h523jQ1ZOUh Efju4cy9hEQdeEFcxEaBPKR3q6MMWW5frDB/UrUfopFnD/krdXcbYkTWO9DTjbJj EW+uMWfJzDGMBQDvRqprNrdYrLETgnAEv5ut7XSgyuu32+Atq/uot6fZmZ1XcfIQ RA45INBmXbt4YWhJ2cGJ3Zjzfzc8t7omIfWVgziSOMBi7gEnvEbCtj9E3X1ywltl +iNhsRfdfa8O65dJT+yOQZuQnJ0RGKJxAJFhlkO0dtl4ahjusE8M/0CqiX8nfJ4U xwEUBTdztukczgKRhj660f/wycGzUGz071LjygQ8kxqqLlUyXWGs3WigvBXxBNW1 lWqyBBOk61LoiQ4TCLFh5mowSPA81u3rdlYLwK723+RgRwv5jAeMNb5XoF8JcAIs 4RcbK5PHnVvv5gZRauiO4lhYAZY= =L4hB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I have been unable to post the thread dump because of size no matter how much I send under the 1 MB rule. Is there another way I can send it to you. Thanks. I do see a lot of Blocked messages, see example. I was not able to post the whole dump. "http-nio-9080-exec-305" #3888 daemon prio=5 os_prio=0 tid=0x1f445000 nid=0x230 waiting for monitor entry [0x4341d000] java.lang.Thread.State: BLOCKED (on object monitor) at com.mincron.api.restlet.dm.ProductDM.getCategoryItemList(Unknown Source) - waiting to lock <0x000696269dc0> (a java.lang.Class for com.mincron.api.restlet.dm.ProductDM) at com.mincron.api.restlet.resource.CategoryItemListResource.retrieve(Unknown Source) - Darin
Re: TomCat 8.5.23 application not responding
From: Christopher Schultz To: users@tomcat.apache.org Date: 11/02/2017 02:28 PM Subject:Re: TomCat 8.5.23 application not responding -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darin, On 11/2/17 12:55 PM, dbol...@dsginc.biz wrote: > I have a TomCat 8.5.23 service running on a Windows 2008 R2. It is > currently running a third party web commerce application. It will > run great until randomly one day the application will stop > responding. When you try to go to the application URL it sits and > spins. I look at the catalina log and found the below errors at > the time it stop responding. Is this a tomcat configuration issue > or application related. > > I see three specific warning/severe messages in Tomcat. > > Error one: 02-Nov-2017 10:03:23.787 WARNING > [http-nio-9080-exec-402] > com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getForComponent > Unable to find component with ID searchPattern in view. > > Then right after there is a severe message error 2: > > 02-Nov-2017 10:03:23.896 SEVERE [http-nio-9080-exec-455] > org.restlet.engine.http.adapter.ServerAdapter.commit An exception > occured writing the response entity > org.apache.catalina.connector.ClientAbortException: > java.io.IOException: An established connection was aborted by the > software in your host machine > > Then the warning messages constant all the way down until this all > the way down until we had to reboot the service because of no > response. > > 02-Nov-2017 10:03:23.896 WARNING [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call: 02-Nov-2017 10:03:23.896 INFO > [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call java.lang.IllegalStateException: > Cannot call sendError() after the response has been committed Can you take some thread dumps to show what the Tomcat threads are doing? One thread dump will probably be very long, but go ahead and post the whole thing to the list. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln7ckIdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh8og/8CataalwbNgVBl+uK f3q1W5JEOZbXBR2dA3UuR/mtZxHa6azH7UMSiydRpcRVoRvP7z0aeDyGoW/u70MT 23RlkNFDVG5HP6Z6AIBKrDisQDwHYRM9iq2o3vPYW56mgDLC56yxUKnKUATHGpgB MYk0vzicWawt1+zF/GE7qshTtubt5HgqmFFckhFPWWTRqsvkiyYIbkq9o6iUNHZZ MMPwe9ppeKOVew2c5csqLaSS9MUdbYerEblvho7WfQSW8YjtL6UO2h523jQ1ZOUh Efju4cy9hEQdeEFcxEaBPKR3q6MMWW5frDB/UrUfopFnD/krdXcbYkTWO9DTjbJj EW+uMWfJzDGMBQDvRqprNrdYrLETgnAEv5ut7XSgyuu32+Atq/uot6fZmZ1XcfIQ RA45INBmXbt4YWhJ2cGJ3Zjzfzc8t7omIfWVgziSOMBi7gEnvEbCtj9E3X1ywltl +iNhsRfdfa8O65dJT+yOQZuQnJ0RGKJxAJFhlkO0dtl4ahjusE8M/0CqiX8nfJ4U xwEUBTdztukczgKRhj660f/wycGzUGz071LjygQ8kxqqLlUyXWGs3WigvBXxBNW1 lWqyBBOk61LoiQ4TCLFh5mowSPA81u3rdlYLwK723+RgRwv5jAeMNb5XoF8JcAIs 4RcbK5PHnVvv5gZRauiO4lhYAZY= =L4hB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I have been unable to post the thread dump because of size no matter how much I send under the 1 MB rule. Is there another way I can send it to you. Thanks.
Re: TomCat 8.5.23 application not responding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darin, On 11/2/17 12:55 PM, dbol...@dsginc.biz wrote: > I have a TomCat 8.5.23 service running on a Windows 2008 R2. It is > currently running a third party web commerce application. It will > run great until randomly one day the application will stop > responding. When you try to go to the application URL it sits and > spins. I look at the catalina log and found the below errors at > the time it stop responding. Is this a tomcat configuration issue > or application related. > > I see three specific warning/severe messages in Tomcat. > > Error one: 02-Nov-2017 10:03:23.787 WARNING > [http-nio-9080-exec-402] > com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getForComponent > Unable to find component with ID searchPattern in view. > > Then right after there is a severe message error 2: > > 02-Nov-2017 10:03:23.896 SEVERE [http-nio-9080-exec-455] > org.restlet.engine.http.adapter.ServerAdapter.commit An exception > occured writing the response entity > org.apache.catalina.connector.ClientAbortException: > java.io.IOException: An established connection was aborted by the > software in your host machine > > Then the warning messages constant all the way down until this all > the way down until we had to reboot the service because of no > response. > > 02-Nov-2017 10:03:23.896 WARNING [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call: 02-Nov-2017 10:03:23.896 INFO > [http-nio-9080-exec-455] > org.restlet.engine.http.HttpServerHelper.handle Error while > handling an HTTP server call java.lang.IllegalStateException: > Cannot call sendError() after the response has been committed Can you take some thread dumps to show what the Tomcat threads are doing? One thread dump will probably be very long, but go ahead and post the whole thing to the list. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln7ckIdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh8og/8CataalwbNgVBl+uK f3q1W5JEOZbXBR2dA3UuR/mtZxHa6azH7UMSiydRpcRVoRvP7z0aeDyGoW/u70MT 23RlkNFDVG5HP6Z6AIBKrDisQDwHYRM9iq2o3vPYW56mgDLC56yxUKnKUATHGpgB MYk0vzicWawt1+zF/GE7qshTtubt5HgqmFFckhFPWWTRqsvkiyYIbkq9o6iUNHZZ MMPwe9ppeKOVew2c5csqLaSS9MUdbYerEblvho7WfQSW8YjtL6UO2h523jQ1ZOUh Efju4cy9hEQdeEFcxEaBPKR3q6MMWW5frDB/UrUfopFnD/krdXcbYkTWO9DTjbJj EW+uMWfJzDGMBQDvRqprNrdYrLETgnAEv5ut7XSgyuu32+Atq/uot6fZmZ1XcfIQ RA45INBmXbt4YWhJ2cGJ3Zjzfzc8t7omIfWVgziSOMBi7gEnvEbCtj9E3X1ywltl +iNhsRfdfa8O65dJT+yOQZuQnJ0RGKJxAJFhlkO0dtl4ahjusE8M/0CqiX8nfJ4U xwEUBTdztukczgKRhj660f/wycGzUGz071LjygQ8kxqqLlUyXWGs3WigvBXxBNW1 lWqyBBOk61LoiQ4TCLFh5mowSPA81u3rdlYLwK723+RgRwv5jAeMNb5XoF8JcAIs 4RcbK5PHnVvv5gZRauiO4lhYAZY= =L4hB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TomCat 8.5.23 application not responding
I have a TomCat 8.5.23 service running on a Windows 2008 R2. It is currently running a third party web commerce application. It will run great until randomly one day the application will stop responding. When you try to go to the application URL it sits and spins. I look at the catalina log and found the below errors at the time it stop responding. Is this a tomcat configuration issue or application related. I see three specific warning/severe messages in Tomcat. Error one: 02-Nov-2017 10:03:23.787 WARNING [http-nio-9080-exec-402] com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getForComponent Unable to find component with ID searchPattern in view. Then right after there is a severe message error 2: 02-Nov-2017 10:03:23.896 SEVERE [http-nio-9080-exec-455] org.restlet.engine.http.adapter.ServerAdapter.commit An exception occured writing the response entity org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine Then the warning messages constant all the way down until this all the way down until we had to reboot the service because of no response. 02-Nov-2017 10:03:23.896 WARNING [http-nio-9080-exec-455] org.restlet.engine.http.HttpServerHelper.handle Error while handling an HTTP server call: 02-Nov-2017 10:03:23.896 INFO [http-nio-9080-exec-455] org.restlet.engine.http.HttpServerHelper.handle Error while handling an HTTP server call java.lang.IllegalStateException: Cannot call sendError() after the response has been committed Darin Bolken | Programmer/Systems Support
Re: Tomcat 8.5.23 Initialization PRNG/SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 10/27/17 10:55 AM, George S. wrote: > I'm seeing some strange ssl errors. They're not reproducible > consistently, and I think they're because the PRNG is initializing > after the Connector. Here's some log output: > > 26-Oct-2017 17:04:08.380 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["http-nio-8080"] 26-Oct-2017 17:04:08.429 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["https-jsse-nio-443"] 26-Oct-2017 17:04:08.459 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["ajp-nio-8009"] 26-Oct-2017 17:04:08.492 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 56903 > ms 26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1] > org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom > Creation of SecureRandom instance for session ID generation using > [SHA1PRNG] took [118,978] milliseconds. > > The exception is: > > javax.net.ssl.SSLHandshakeException: Received fatal alert: > handshake_failure at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown > Source) at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown > Source) at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown > Source) at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown > Source) at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unk nown > > Source) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown > Source) at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown > Source) at > sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown > Source) at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect( Unknown > > Source) > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown > > Source) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unkn own > Source) > > > Has anyone else seen something like this? The app is making an > internal SSL connection to another servlet. I don't know why they > didn't use a RequestDispatcher and do .include(), but it's not my > code. > > Anyhow, am I right that the exception is probably related to the > connectors coming up before the PRNG? These things are not connected -- this is just a coincidence. The startup time you are seeing is for seeding the secure random-number generator that produces session identifiers. The error has to do with TLS cipher suite negotiations: there is either a mismatch between protocols/cipher suites supported by both client and server, or you are connecting to a service which requires a client certificate and none has been provided. I would scan the service to see what protocols/cipher suites are actually supported and then check to see what the client has been configured to support. My experience is that nobody ever bothers to configure the client, and that the defaults are "connect to anything!", so this does seem a little odd. More information is necessary at this point. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3M2cACgkQHPApP6U8 pFg78w//Y+hte1gG6rS6QC50pdvB1juLW6wD1JIhF/mrc6BPZYjlFhsS5LrJfHSM Nb65m+9T6ic+LKnRhC8ftWQf4/BY2ZgFqOoWxnYydwa8TANSC43OhhskzKYq/mlR 4yRkQ0mi7tSB0EuF+z15v8y1myWz5RYQ/Eaj+XMjJn0p4mQHocU5QtZ1YxjMM15M l4oXxAJeUjb6OSotTwv+GaiIfNDICL169pQcDZiUVTEOkONrhDWe0Nfv64u9QWRc SzLx0zSSJleLuVBI8Uu7IvrB9MUw1HSAOh4bdpcw8b69HTK1Dw7lPA35ACmqzmm1 TbmltyCTLSBPHMb+R3Q71tUAfDTz+1DNPn97Ai5453l1Z/vmwqfo7vyr6tV3P2Zg Td3XdL1wD3ICiR/z1tgubeGEHUwlljmnaARoHUU6lfLBj/wjVppw/8d3ODCr+kb1 biwNRKj/Tac7abRD/+K/ZUk1K0iPt5cOZBIRuvYr5FmuMQyxalLDikUM7UR5MWiW mfT8tEubk85D36EfL0nljFGCOFzjpSEmZUC4RzSZTQT/UQjuriPPze8+NvsDIL/1 Jt3uy3fUk0plaPg/0cEs5dhw9dF4XxHsyYjTV/fQXI/HnMR2x8Ct5QmkynPNEnCu NGTMEhMJL2cYN3fWbVcvUHfHn5uLQpMaUNj3uB3ArECikeDMgJM= =YzS7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, (This turned out to be quite long. I honestly think it's worth reading.) On 10/27/17 5:32 PM, André Warnier (tomcat) wrote: > There seem to be a recrudescence of interventions on this list > about SSL/HTTPS, and associated discussions about the usage of > various randomness sources. I found this article interesting : > https://www.2uo.de/myths-about-urandom/ Thanks for posting this. I have a couple of comments. 1. The author provides very few references. 2. The author seems to be arguing /strongly/ in favor of universal use of /dev/urandom, except the the time he briefly concedes that long-lived keys probably ought to use /dev/random So basically, he has expanded random(4) into a semi-didactic rant about why people use "common knowledge" instead of real information. I mentioned in a recent thread that maybe using haveged[1] on a virtual machine might not be a good idea. My argument against goes something like this: 1. Users should always have a choice between /dev/random and /dev/urando m. 2. If you choose to use /dev/random for whatever reason (e.g. to generate long-lived TLS/PGP/SSH keys), then you are expecting to get the kind of entropy and randomness that device is documented to provide. 3. Virtual machines pull the wool over the eyes of the guest OS in such a way to make all kinds of "hardware" events less random than one would expect from bare-metal. 4. This tool therefore has the high potential to make /dev/random behave like /dev/urandom, therefore this tool removes choice from the user, the OS, and everything else. A user drawing from /dev/random is expecting one type of randomness and getting another, and it's possible that the user has no idea it's happening. I would never recommend to anyone that they switch all of their uses of /dev/urandom to /dev/random (not vice-versa). But I definitely would recommend against anything that switches the semantics of /dev/random to anything other than what it already does. It's worth mentioning that there has been a lot of confusion over the years as to what Java uses for its seeds -- at least the Sun/Oracle flavor. For a time, the source was /dev/random, then /dev/urandom, then a time where both /dev/random and /dev/urandom were somewhat transparently aliased to one another so that if you wanted to get the REAL one you wanted, you had to specify things like /dev/./urandom (or /dev/./random) because the JVM would decide it knew better than you did about where you wanted your entropy to come from. As of this moment, the $JAVA_HOME/jre/lib/security/java.security file on an arbitrary server I have available to me has the following line of configuration in it: securerandom.source=file:/dev/random There is nothing in the comments surrounding that setting that suggests anything other than /dev/random will be used. Have a look at [2] which has references to the history of the whole thing and a (reasonably) current statement about what's being used in modern JVMs. I'm glad I read the Oracle Java 8 security update (which I hadn't read before) ... I never knew that there was a new SecureRandom.getInstanceStrong method to get the "Strongest source of randomness" available to the JVM. Sadly, you can't select the provider and algorithm -- while that choice might actually be counter-productive. Remember that entropy is only required when seeding a random-number generator such as java.util.Random or java.security.SecureRandom. Once the algorithm has been seeded, no additional entropy is necessary for the lifetime of PRNGs. Certain algorithms may choose to mix-in some entropy at intervals during their lifetime, but it's not strictly necessary. IMHO, when it comes to generating long-lived keys, use of Java is not necessary because there are better tools available. I don't know of anyone who uses Java to generate PGP or SSH keys, for example. keytool obviously does RSA and it the "tool of choice" when it comes to generating new server keys for TLS with Java-based servers. I tend not to use Java for and server-side TLS -- I use non-Java-based reverse-proxies for that purpose -- and so use of keytool is irrelevant for me. When using keytool, I highly suspect that SecureRandom.getInstanceStrong is in use so using Java for such high-security keys does in fact seem reasonable. But for online use? Using /dev/urandom is certainly acceptable. Unfortunately, it looks like Java's Random/SecureRandom classes don't allow the client code to choose the source of randomness. That means starting-up Tomcat will require a bit of entropy to come from /dev/random -- at least on Java 8 and later -- and that may lead to long startup times while the (blocking) device satisfies itself -- and client code. This presents a conundrum for system administrators who must then decide amongst the following options for how to deal with long startup times: 1. Use something like haveged 2. Switch the JVM from /dev/random to /dev/urandom
Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]
On 28.10.2017 00:54, Bob Hall wrote: > On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) wrote: > > > There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and associated discussions about the usage of various randomness sources.> I found this article interesting :> https://www.2uo.de/myths-about-urandom/ André, [OT] or not, thanks for adding a word to my vocabulary and for the article; recrudescence sounds better in French: Google Translate Well, Merriam-Webster defines it as follows : Definition of recrudescence :a new outbreak after a period of abatement or inactivity :renewal a recrudescence of the symptoms a recrudescence of guerrilla warfare .. which is pretty much what I meant. It may be however that the fact that I deal with a lot of medical literature in my professional life, is somewhat colo(u)ring my English vocabulary. ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]
> On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) > wrote: > > > There seem to be a recrudescence of interventions on this list about >SSL/HTTPS, and > associated discussions about the usage of various randomness sources.> I > found this article interesting :> https://www.2uo.de/myths-about-urandom/ André, [OT] or not, thanks for adding a word to my vocabulary and for the article; recrudescence sounds better in French: Google Translate | | | | Google Translate Google's free service instantly translates words, phrases, and web pages between English and over 100 other lang... | | | - Bob
[maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]
There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and associated discussions about the usage of various randomness sources. I found this article interesting : https://www.2uo.de/myths-about-urandom/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.23 Initialization PRNG/SSL
On 27.10.2017 16:55, George S. wrote: I'm seeing some strange ssl errors. They're not reproducible consistently, and I think they're because the PRNG is initializing after the Connector. Here's some log output: 26-Oct-2017 17:04:08.380 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"] 26-Oct-2017 17:04:08.429 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["https-jsse-nio-443"] 26-Oct-2017 17:04:08.459 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"] 26-Oct-2017 17:04:08.492 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 56903 ms 26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [118,978] milliseconds. If that means actually 118 thousand 978 milliseconds (just shy of 2 minutes), that looks like a lot. According to the little I have been able to grab while perusing this list, that would indicate some serious difficulty for that host in generating sufficient entropy. Maybe time to read the FAQ : https://wiki.apache.org/tomcat/HowTo/FasterStartUp Item 3. The exception is: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) Has anyone else seen something like this? The app is making an internal SSL connection to another servlet. That does indeed not seem to make a lot of sense, unless this servlet could possibly be running on another server. I don't know why they didn't use a RequestDispatcher and do .include(), but it's not my code. Anyhow, am I right that the exception is probably related to the connectors coming up before the PRNG? Tomcat is starting a Connector ["https-jsse-nio-443"], for which I suppose it also needs entropy. Does the log say when that Connector is actually finished with starting up ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5.23 Initialization PRNG/SSL
I'm seeing some strange ssl errors. They're not reproducible consistently, and I think they're because the PRNG is initializing after the Connector. Here's some log output: 26-Oct-2017 17:04:08.380 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"] 26-Oct-2017 17:04:08.429 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["https-jsse-nio-443"] 26-Oct-2017 17:04:08.459 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"] 26-Oct-2017 17:04:08.492 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 56903 ms 26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [118,978] milliseconds. The exception is: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) Has anyone else seen something like this? The app is making an internal SSL connection to another servlet. I don't know why they didn't use a RequestDispatcher and do .include(), but it's not my code. Anyhow, am I right that the exception is probably related to the connectors coming up before the PRNG? -- George S. *MH Software, Inc.* Voice: 303 438 9585 http://www.connectdaily.com
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
On Thu, Oct 26, 2017 at 3:00 PM, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> On 10/16/17 9:43 AM, Chris Cheshire wrote:
>> On Fri, Oct 13, 2017 at 5:00 PM, Christopher Schultz
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>
>>> When you say you have "autocommit disabled in mysql config" what
>>> do you mean?
>>>
>>
>> /etc/my.cnf : [mysqld] autocommit=0
>>
>> This turns off autocommit off as a default for all connections.
>
> It only affects connections from MySQL's "mysql" command-line client.
> It does not affect e.g. Java-based clients.
>
It's in the [mysqld] section of my.cnf so it is supposed to be at a
server level.
I do have stuff in the [mysql] section that affects the command line client
behaviour only.
>> I need this at a minimum for the mysql client, but in the absence
>> of any other configuration it should be the default for a
>> connection from any client.
>
> The JDBC spec says that all connections are auto-commit unless
> otherwise specified. So if you are creating your own connections or
> using e.g. a connection-pool then you'll have to make sure that you
> configure them to be NOT auto-commit. This is not a setting that you
> can control from the server.
>
> More below.
>
I was doing that anyway in both the pool configuration and when
the connection is grabbed from the pool. I've since changed the code to not
touch the autocommit setting and leave that up to the datasource
(resource config in context.xml)
>>> On 10/13/17 10:17 AM, Chris Cheshire wrote:
As a further test I just took out my explicit rollback in my
DAOFactory close() method, and swapped back to commons dbcp.
Added an update that wasn't explicitly committed, and it
correctly did not get committed when the connection was closed.
Swapped back to tomcat dbcp and repeated, it got committed
without an explicit commit statement.
I'm really puzzled as to why *I* have to explicitly rollback
on close if autocommit is not enabled, instead of tomcat dbcp
handling that when commons dbcp appears to do it.
>>>
>>> No connection pool can read your mind. If you begin a transaction
>>> (or never start one), you must either commit or rollback. Merely
>>> calling close() does not explicitly cause either of those to be
>>> called.
>>>
>>
>> And that's just it. If I don't explicitly commit, then why are
>> changes being committed when the connection is closed and returned
>> back to the pool?
>>
If I do
daoFactory = new MySQLDAOFactoryImpl(getDataSource());
// update #1 daoFactory.commit()
// update #2 daoFactory.close();
then update #2 is being committed.
>>>
>>> I'm curious why you are doing "update #2" without either COMMIT
>>> or ROLLBACK. That seems like ... a mistake.
>>>
>>
>> Correct. This is an example to illustrate a mistake I found in my
>> code. I found a servlet that actually wasn't explicitly committing
>> when it should have been, yet everything it was doing was being
>> committed to the database.
>>
>>> - From the Connection.close() javadoc:
>>>
>>> " It is strongly recommended that an application explicitly
>>> commits or rolls back an active transaction prior to calling the
>>> close method. If the close method is called and there is an
>>> active transaction, the results are implementation-defined. "
>>>
>>
>> If a commit is not being explicitly issued, then the commit
>> behaviour should honor that of the connection, yes?
>
> Yes, but it's more complicated than that. Any change to the
> connection's settings (which happen ALL THE TIME when the connection
> is being returned to a connection pool) will cause an implicit COMMIT.
> That's why it's super important for you to either COMMIT or ROLLBACK
> yourself.
>
> Note that "autocommit = false" doesn't mean "autorollback=true".
> Best-case scenario for you there is that the transaction gets
> committed *later* when another piece of your code grabs a connection
> from the pool, does its work (successfully) and issues a COMMIT.
>
> It's just NOT the pool's job nor the driver's job to clean-up after
> any messes created by your code.
Agreed, however since it was acting differently than the commons
pool I mistakenly attributed the behaviour to tomcat jdbc instead.
>
>>> There *is* an implicit COMMIT executed if the autocommit flag is
>>> flipped for any reason, either true->false or false->true.
>>>
>>> If you have autocommit=false in your configuration
>>> (which you do), then calling setAutoCommit(false) shouldn't do
>>> anything.
>>>
If I put in this in the close() method of my DAO Factory
if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }
before the close() call, then update #2 is correctly not
getting committed.
>>>
>>> This is probably the wrong approach: your close() method doesn't
>>> know whether it's better to call commit() or rollback(), so it
>>> should do neit
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris and Keiichi, On 10/17/17 5:31 PM, Chris Cheshire wrote: > On Tue, Oct 17, 2017 at 3:44 AM, Keiichi Fujino > wrote: >> Hi >> >> You have set >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". In other >> words, you do not use (tomcat)DBCP, you are using Tomcat >> jdbc-pool. > > That's what I meant sorry. Was comparing to commons-dbcp and went > dyslexic on the acronyms. > >> >> In DBCP, the default of rollbackOnReturn attribute is true. >> However, in Tomcat jdbc-pool, the default of rollbackOnReturn( >> and commitOnReturn ) attribute are false. >> >> see: >> http://commons.apache.org/proper/commons-dbcp/configuration.html >> http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html >> >> > > Now that explains it entirely. Thank you so much! > > Part of this is me failing to RTFM entirely, and then part is the > nature of configuration references - if you don't know what you are > looking for it is easy to miss important details. It would be > helpful if that page explained some of the fundamental differences > from a usage perspective (not just implementation improvements) but > that's another story. I didn't realize that these two libraries had different default semantics. IMO, Tomcat's jdbc-pool behaves _correctly_ in that it doesn't issue an unnecessary ROLLBACK on every connection returned to the pool. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnyMUcdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFij4w//Q5tGBgwdcXsT9k/V Raop4RalDLSeJNhTDY2FIMpDNHnvcq45BrOqkO3GhukyuNxpn/aJrUsE6ucbXN/3 jeb32JDEJ5f8FK5A6t9ZCeEG84p5BNDEfQUJEJQA5G67tBrhYzGfbW0t4X4qMyuM l/xrVBLVP9JCLdjWUg/VnTyYhNKZGkIHYXzX5QtmZtjTRH+OBzCTuTT4B54WhkWM MIFn5WYXxOnP6/+nR4f4rcV8VPKiJOoYuTv+dxt/Ih4IiGPNh+xUIzNS+lCTiagK rsWDq51pqkH05nHdJTZ2+aZJEs/mFWXaCyjU3BOvIEPaUKaBJgjxjGBrIL1Tb/a9 jVEU3WrRJ3jNSNGYeN9kBfaL2dtB4W/H1btk1WAu39IuAdD/ZEcr8VgyIbteP6ar StHXm2g5xt88X8ndgIo/2jdZisZ8LBNFksZ5yMXRuJckw3FN/YeLzHbe3gbPFXtv K4xMFlI8OZFqr89EuNzzQjsris0gy6k3EFfQGz5tJDK7yiTNIEBfQbjGj9eFyYoA 7V2f7HvUIVmiNnRpCdg0CihdOypzIrXAZePOYTJGzkER0pUlGqt4ue4+6o5i8GSf lap1sScK7Q6FiOGAvtQ3ZE+WMXvUFqGrs//O0pIi67KwXXHu+WsDV7av1BupZ0/F hFkomQ3hHYAJoDoEJJHkn7jRXpY= =zG27 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
On 10/16/17 9:43 AM, Chris Cheshire wrote:
> On Fri, Oct 13, 2017 at 5:00 PM, Christopher Schultz
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>
>> When you say you have "autocommit disabled in mysql config" what
>> do you mean?
>>
>
> /etc/my.cnf : [mysqld] autocommit=0
>
> This turns off autocommit off as a default for all connections.
It only affects connections from MySQL's "mysql" command-line client.
It does not affect e.g. Java-based clients.
> I need this at a minimum for the mysql client, but in the absence
> of any other configuration it should be the default for a
> connection from any client.
The JDBC spec says that all connections are auto-commit unless
otherwise specified. So if you are creating your own connections or
using e.g. a connection-pool then you'll have to make sure that you
configure them to be NOT auto-commit. This is not a setting that you
can control from the server.
More below.
>> On 10/13/17 10:17 AM, Chris Cheshire wrote:
>>>
>>>
>>> As a further test I just took out my explicit rollback in my
>>> DAOFactory close() method, and swapped back to commons dbcp.
>>> Added an update that wasn't explicitly committed, and it
>>> correctly did not get committed when the connection was closed.
>>> Swapped back to tomcat dbcp and repeated, it got committed
>>> without an explicit commit statement.
>>>
>>> I'm really puzzled as to why *I* have to explicitly rollback
>>> on close if autocommit is not enabled, instead of tomcat dbcp
>>> handling that when commons dbcp appears to do it.
>>
>> No connection pool can read your mind. If you begin a transaction
>> (or never start one), you must either commit or rollback. Merely
>> calling close() does not explicitly cause either of those to be
>> called.
>>
>
> And that's just it. If I don't explicitly commit, then why are
> changes being committed when the connection is closed and returned
> back to the pool?
>
>>> If I do
>>>
>>> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>>>
>>> // update #1 daoFactory.commit()
>>>
>>> // update #2 daoFactory.close();
>>>
>>> then update #2 is being committed.
>>
>> I'm curious why you are doing "update #2" without either COMMIT
>> or ROLLBACK. That seems like ... a mistake.
>>
>
> Correct. This is an example to illustrate a mistake I found in my
> code. I found a servlet that actually wasn't explicitly committing
> when it should have been, yet everything it was doing was being
> committed to the database.
>
>> - From the Connection.close() javadoc:
>>
>> " It is strongly recommended that an application explicitly
>> commits or rolls back an active transaction prior to calling the
>> close method. If the close method is called and there is an
>> active transaction, the results are implementation-defined. "
>>
>
> If a commit is not being explicitly issued, then the commit
> behaviour should honor that of the connection, yes?
Yes, but it's more complicated than that. Any change to the
connection's settings (which happen ALL THE TIME when the connection
is being returned to a connection pool) will cause an implicit COMMIT.
That's why it's super important for you to either COMMIT or ROLLBACK
yourself.
Note that "autocommit = false" doesn't mean "autorollback=true".
Best-case scenario for you there is that the transaction gets
committed *later* when another piece of your code grabs a connection
from the pool, does its work (successfully) and issues a COMMIT.
It's just NOT the pool's job nor the driver's job to clean-up after
any messes created by your code.
>> There *is* an implicit COMMIT executed if the autocommit flag is
>> flipped for any reason, either true->false or false->true.
>>
>> If you have autocommit=false in your configuration
>> (which you do), then calling setAutoCommit(false) shouldn't do
>> anything.
>>
>>> If I put in this in the close() method of my DAO Factory
>>>
>>> if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }
>>>
>>> before the close() call, then update #2 is correctly not
>>> getting committed.
>>
>> This is probably the wrong approach: your close() method doesn't
>> know whether it's better to call commit() or rollback(), so it
>> should do neither.
>
> I realise this too, however I have to have it in otherwise if an
> exception is thrown, then work is being committed regardless of the
> fact that I have autocommit turned OFF in 3 levels, all the way
> back to the mysqld configuration.
The mysqld configuration is not relevant, here. Are you able to run
your code through a debugger to see when the COMMIT is happening?
> This behaviour does not happen with commons dbcp, only tomcat dbcp.
> There is a difference in default behaviour between the two pools
> when a transaction is not explicitly committed or rolled back when
> a connection is closed and returned to the pool.
Can you create a SSCCE test-case which demonstrates this problem where
it behaves on
Re: Checksum fail for apache-tomcat-8.5.23-windows-x86.zip
2017-10-23 16:40 GMT+03:00 Bill Munro : > Hi, > > > I downloaded the file from all mirror sites (including backups), but I get a > different checksum than the one on the apache site. I am using fsum sha1. > Are the checksums on the site incorrect, or is fsum wrong? Maybe you are comparing with checksum of a different file? E.g. windows-x86.zip vs windows-x64.zip vs .zip ? The correct sha1: 5992ca5bf02a6ae6d901eb22e7d3309061b26e42 *apache-tomcat-8.5.23-windows-x86.zip sha256: acca2ce6217da70beb8f6b0d58054f2133276bd7328ff51ca51ae0125c1cf586 *apache-tomcat-8.5.23-windows-x86.zip The value of sha256 can be used to search VirusTotal: https://www.virustotal.com/file/acca2ce6217da70beb8f6b0d58054f2133276bd7328ff51ca51ae0125c1cf586/analysis/ First submission 2017-10-02 08:36:18 UTC Officially, the recommended way to verify a file is to check its PGP signature. https://www.apache.org/info/verification.html Verifying the signature, using GPG (using the one included with Git for Windows): (omitting some unimportant messages) $ gpg --keyserver pgpkeys.mit.edu --recv-key 33C60243 gpg: requesting key 33C60243 from hkp server pgpkeys.mit.edu gpg: key 33C60243: public key "Mark E D Thomas " imported gpg: key 33C60243: public key "Mark E D Thomas " imported gpg: no ultimately trusted keys found gpg: Total number processed: 2 gpg: imported: 2 (RSA: 1) $ gpg --fingerprint 33C60243 pub 1024R/33C60243 2014-06-16 [revoked: 2016-08-16] Key fingerprint = B65C A985 6C76 39CD 9D17 7D0E 5385 81D4 33C6 0243 uid Mark E D Thomas pub 1024D/33C60243 2004-09-12 Key fingerprint = DCFD 35E0 BF8C A734 4752 DE8B 6FB2 1E89 33C6 0243 uid Mark E D Thomas uid Mark E D Thomas uid Mark E D Thomas sub 2048g/0BECE548 2004-09-12 $ gpg --verify apache-tomcat-8.5.23-windows-x86.zip.asc apache-tomcat-8.5.23-windows-x86.zip gpg: Signature made 28 сен 2017 г. 13:31:21 RTZ using DSA key ID 33C60243 gpg: Good signature from "Mark E D Thomas " gpg: aka "Mark E D Thomas " gpg: aka "Mark E D Thomas " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCFD 35E0 BF8C A734 4752 DE8B 6FB2 1E89 33C6 0243 The footprint is the same as of this key in https://www.apache.org/dist/tomcat/tomcat-8/KEYS For ages I used md5sum.exe and sha1sum.exe from GNU CoreUtils package for Windows, http://gnuwin32.sourceforge.net/ http://gnuwin32.sourceforge.net/packages/coreutils.htm Nowadays I use the unix tools bundles with Git for Windows. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Checksum fail for apache-tomcat-8.5.23-windows-x86.zip
Hi, I downloaded the file from all mirror sites (including backups), but I get a different checksum than the one on the apache site. I am using fsum sha1. Are the checksums on the site incorrect, or is fsum wrong? Bill
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
On Tue, Oct 17, 2017 at 3:44 AM, Keiichi Fujino wrote: > Hi > > You have set factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". > In other words, you do not use (tomcat)DBCP, you are using Tomcat jdbc-pool. That's what I meant sorry. Was comparing to commons-dbcp and went dyslexic on the acronyms. > > In DBCP, the default of rollbackOnReturn attribute is true. > However, in Tomcat jdbc-pool, the default of rollbackOnReturn( and > commitOnReturn > ) attribute are false. > > see: > http://commons.apache.org/proper/commons-dbcp/configuration.html > http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html > > Now that explains it entirely. Thank you so much! Part of this is me failing to RTFM entirely, and then part is the nature of configuration references - if you don't know what you are looking for it is easy to miss important details. It would be helpful if that page explained some of the fundamental differences from a usage perspective (not just implementation improvements) but that's another story. Cheers, Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
Hi
You have set factory="org.apache.tomcat.jdbc.pool.DataSourceFactory".
In other words, you do not use (tomcat)DBCP, you are using Tomcat jdbc-pool.
In DBCP, the default of rollbackOnReturn attribute is true.
However, in Tomcat jdbc-pool, the default of rollbackOnReturn( and
commitOnReturn
) attribute are false.
see:
http://commons.apache.org/proper/commons-dbcp/configuration.html
http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html
2017-10-12 6:21 GMT+09:00 Chris Cheshire :
> Working on a migration from 7 to 8.5, and in it I am now using the
> tomcat dbcp, instead of apache commons dbcp. I have found that with no
> other changes to the db code (except the factory param for the
> resource), it is working fine other than there is an implicit commit
> happening when I close a connection, even with autocommit turned off
> in mysql config, resource config AND in my code.
>
> Resource config :
>
>auth="Container"
> type="javax.sql.DataSource"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://localhost:3306/mydb?useUnicode=true&
> characterEncoding=utf8&useSSL=false"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> username=""
> password=""
> maxActive="150"
> maxIdle="25"
> maxWait="6"
> removeAbandoned="true"
> removeAbandonedTimeout="300"
> logAbandoned="true"
> validationQuery="/* ping */"
> testOnBorrow="true"
> testWhileIdle="true"
> timeBetweenEvictionRunsMillis="60"
> defaultAutoCommit="false" />
>
> Only thing changed in that from 7.x to 8.5.x is the factory was
> org.apache.commons.dbcp.BasicDataSourceFactory. I am using Connector/J
> 5.1.44 (latest version).
>
>
> Getting a connection boils down to this in my code (pieces pulled out
> of factories and other classes)
>
> (Support class in web code)
> public static DataSource getDataSource() {
> try {
> return (DataSource)new
> InitialContext().lookup("java:comp/env/" +
> ServletContextParameters.getDatabaseResourceName());
> }
> catch (NamingException ex) {
> throw new RuntimeException("unable to find datasource", ex);
> }
> }
>
>
> (DAO Factory implementation)
> public MySQLDAOFactoryImpl(@NotNull DataSource dataSource) {
> this.dataSource = dataSource;
>
> try {
> this.dbConn = this.dataSource.getConnection();
> this.dbConn.setAutoCommit(false);
> this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_
> COMMITTED);
> }
> catch (SQLException ex) {
> throw new DAOException("unable to get database connection", ex);
> }
> }
>
> @Override
> public void close() {
> try {
> if (this.dbConn != null) {
> this.dbConn.close();
> }
> }
> catch (SQLException ex) {
> throw new DAOException("error closing database connection", ex);
> }
> }
>
>
> If I do
>
> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>
> // update #1
> daoFactory.commit()
>
> // update #2
> daoFactory.close();
>
> then update #2 is being committed.
>
> If I put in this in the close() method of my DAO Factory
>
> if (!this.dbConn.getAutoCommit()) {
> this.dbConn.rollback();
> }
>
> before the close() call, then update #2 is correctly not getting committed.
>
> I looked back through the recent tomcat changelogs, and found a
> reference to https://bz.apache.org/bugzilla/show_bug.cgi?id=61425
> under the 8.5.21 release which looks like it might be addressing this
> problem. However, when I download the source for 8.5.23, there is no
> org.apache.tomcat.jdbc directory so I can't dive in there.
>
> Anyone else experienced this? Hopefully I am just missing something
> obvious.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
>
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
On Fri, Oct 13, 2017 at 5:00 PM, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> When you say you have "autocommit disabled in mysql config" what do
> you mean?
>
/etc/my.cnf :
[mysqld]
autocommit=0
This turns off autocommit off as a default for all connections. I need
this at a minimum
for the mysql client, but in the absence of any other configuration it
should be the
default for a connection from any client.
> On 10/13/17 10:17 AM, Chris Cheshire wrote:
>>
>>
>> As a further test I just took out my explicit rollback in my
>> DAOFactory close() method, and swapped back to commons dbcp. Added
>> an update that wasn't explicitly committed, and it correctly did
>> not get committed when the connection was closed. Swapped back to
>> tomcat dbcp and repeated, it got committed without an explicit
>> commit statement.
>>
>> I'm really puzzled as to why *I* have to explicitly rollback on
>> close if autocommit is not enabled, instead of tomcat dbcp handling
>> that when commons dbcp appears to do it.
>
> No connection pool can read your mind. If you begin a transaction (or
> never start one), you must either commit or rollback. Merely calling
> close() does not explicitly cause either of those to be called.
>
And that's just it. If I don't explicitly commit, then why are changes being
committed when the connection is closed and returned back to the pool?
>> If I do
>>
>> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>>
>> // update #1 daoFactory.commit()
>>
>> // update #2 daoFactory.close();
>>
>> then update #2 is being committed.
>
> I'm curious why you are doing "update #2" without either COMMIT or
> ROLLBACK. That seems like ... a mistake.
>
Correct. This is an example to illustrate a mistake I found in my code. I
found a servlet that actually wasn't explicitly committing when it should
have been, yet everything it was doing was being committed to the database.
> - From the Connection.close() javadoc:
>
> "
> It is strongly recommended that an application explicitly commits or
> rolls back an active transaction prior to calling the close method. If
> the close method is called and there is an active transaction, the
> results are implementation-defined.
> "
>
If a commit is not being explicitly issued, then the commit behaviour
should honor that of the connection, yes?
> There *is* an implicit COMMIT executed if the autocommit flag is
> flipped for any reason, either true->false or false->true.
>
> If you have autocommit=false in your configuration (which
> you do), then calling setAutoCommit(false) shouldn't do anything.
>
>> If I put in this in the close() method of my DAO Factory
>>
>> if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }
>>
>> before the close() call, then update #2 is correctly not getting
>> committed.
>
> This is probably the wrong approach: your close() method doesn't know
> whether it's better to call commit() or rollback(), so it should do
> neither.
I realise this too, however I have to have it in otherwise if an
exception is thrown,
then work is being committed regardless of the fact that I have autocommit
turned OFF in 3 levels, all the way back to the mysqld configuration.
This behaviour does not happen with commons dbcp, only tomcat dbcp. There is a
difference in default behaviour between the two pools when a transaction is
not explicitly committed or rolled back when a connection is closed and
returned to the pool.
I use a try-with-resources/finally to open and close my database connections,
thus short of a JVM crash, any exceptions thrown will always close the
connections
and return them to the pool.
Thought: Perhaps the transaction marker is not being reset when a
pooled connection is being handed out to a subsequent request for a
connection, and that new servlet's work is committing the work from the first
servlet that should not have been committed.
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
Sorry, I had the autocommit true/false values mixed up in my mind.
When you say you have "autocommit disabled in mysql config" what do
you mean?
On 10/13/17 10:17 AM, Chris Cheshire wrote:
>
>
> As a further test I just took out my explicit rollback in my
> DAOFactory close() method, and swapped back to commons dbcp. Added
> an update that wasn't explicitly committed, and it correctly did
> not get committed when the connection was closed. Swapped back to
> tomcat dbcp and repeated, it got committed without an explicit
> commit statement.
>
> I'm really puzzled as to why *I* have to explicitly rollback on
> close if autocommit is not enabled, instead of tomcat dbcp handling
> that when commons dbcp appears to do it.
No connection pool can read your mind. If you begin a transaction (or
never start one), you must either commit or rollback. Merely calling
close() does not explicitly cause either of those to be called.
> If I do
>
> daoFactory = new MySQLDAOFactoryImpl(getDataSource());
>
> // update #1 daoFactory.commit()
>
> // update #2 daoFactory.close();
>
> then update #2 is being committed.
I'm curious why you are doing "update #2" without either COMMIT or
ROLLBACK. That seems like ... a mistake.
- From the Connection.close() javadoc:
"
It is strongly recommended that an application explicitly commits or
rolls back an active transaction prior to calling the close method. If
the close method is called and there is an active transaction, the
results are implementation-defined.
"
There *is* an implicit COMMIT executed if the autocommit flag is
flipped for any reason, either true->false or false->true.
If you have autocommit=false in your configuration (which
you do), then calling setAutoCommit(false) shouldn't do anything.
> If I put in this in the close() method of my DAO Factory
>
> if (!this.dbConn.getAutoCommit()) { this.dbConn.rollback(); }
>
> before the close() call, then update #2 is correctly not getting
> committed.
This is probably the wrong approach: your close() method doesn't know
whether it's better to call commit() or rollback(), so it should do
neither.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnhKXEACgkQHPApP6U8
pFhZmw/9FN376aEpeGwzLRnpWy0jIo7EezNXeV4G5Jtj1slDeqbFMOYcm/3bdSEt
sa+9FwHbe9gKMyeLWp3TJbDZ8F0RI+e2CIYV37XAchrDvpb+f80M+SjzPyuovO6a
9wRtbekKd8mbIfpGTfokjW+pNIJBbAJvZfh0UGFJP+VRX5XoE6MLzw60OnEMlmLP
7IFAdvM0t816Nuh7yJIg63I3eHYB3P7cx01ETEhWyI1oK2LQ50cODfgLoxT3iC+j
f8HAyn8wubZSkC3PKJ/oY8TGaLczSt8M/ANAucZ0mw91j7m93OB+3KGwVczGRUiD
lodMS9RZBsGmNxxzKcCUCmxydat2PRYJSmP/hRR0nQL7xRPiClAi4KJTWFCdn0hc
SNZp8shT9Z5EVBNHJ9z2ippW7K5Xr+U58bYrN+kEmq8jN5UTUcQlDoahwnRbRWV5
CCBX+9P+fd44yWuK5IGkFcuKr68LmZYHarZlL5OTxfretKB7QX9B4o4x6J8PhhFj
vnfJPlQCkKkuRyuSGTneLqM+f+CrQq7nquVxUmgUPF2btqNe1d21/g8AN8+FSdKS
YgiZ/OstBdoDHVxnfxDJQcwY8IG9qg/didN7oaNAdelulcdIFx8Ob7PEdEmXZlrV
o3vs2ntI7dCjfr0vfbvkzqrwXGgEMIPvukggB+DTgRxpYKJfCRM=
=/fEQ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
As a further test I just took out my explicit rollback in my DAOFactory close() method, and swapped back to commons dbcp. Added an update that wasn't explicitly committed, and it correctly did not get committed when the connection was closed. Swapped back to tomcat dbcp and repeated, it got committed without an explicit commit statement. I'm really puzzled as to why *I* have to explicitly rollback on close if autocommit is not enabled, instead of tomcat dbcp handling that when commons dbcp appears to do it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
On Thu, Oct 12, 2017 at 11:16 PM, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> On 10/11/17 5:21 PM, Chris Cheshire wrote:
>> Working on a migration from 7 to 8.5, and in it I am now using the
>> tomcat dbcp, instead of apache commons dbcp.> I have found that
>> with no other changes to the db code (except the factory param for
>> the resource), it is working fine other than there is an implicit
>> commit happening when I close a connection, even with autocommit
>> turned off in mysql config, resource config AND in my code.
> Your complaint is very close to my heart, here. <3
>
> Back in 2003 or so, I posted roughly this exact question to this
> mailing list with a little less ... diplomacy, shall we say?
>
>> try { this.dbConn = this.dataSource.getConnection();
>> this.dbConn.setAutoCommit(false);
>> this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMIT
> TED);
>>
>>
> }
>> catch (SQLException ex) { throw new DAOException("unable to get
>> database connection", ex); }
>
> I'll bet you've had this problem for a really long time, but just
> didn't notice it until now.
>
Nope, only since swapping from commons dbcp (tomcat 7.x) to tomcat
dbcp in development.
I started with 8.5.20 and upgraded yesterday to 8.5.23 and it still
exhibits this behaviour.
> The core problem is that you have autocommit=false in your
> configuration and autocommit=true in your code. If an exception occurs
> and you don't rollback the transaction, the connection pool will reset
> all of the settings to your configured settings (including
> autocommit=true). Setting autocommit=true when autocommit=false
> commits the transaction, which is SUPER surprising to anyone who
> hasn't read the Javadoc[1]
>
I *don't* have autocommit=true in code, unless
this.dbConn.setAutoCommit(false);
doesn't mean what I think it means. You even have it in your example!
> Technically, this happens whether you encounter an exception or not,
> but it's fairly rare to have code that intentionally does this:
>
> conn.setAutoCommit(false);
> // UPDATE ...;
> conn.close();
>
> So, given that this is usually an "exceptional" situation, it's your
> exceptions you need to carefully handle. In fact, you need to do more
> than you are used to doing.
>
> Have a look at this post I did years later when related questions kept
> coming up on the list:
> http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin
> g-pooled-jdbc-connections/
>
I have autocommit set to false in 3 ways :
1) /etc/my.conf : autocommit=0
2) context.xml resource def : defaultAutoCommit=false
3) in code : dbConn.setAutoCommit(false)
When I query autocommit on the connection it returns false, yet
transactions are being committed when I issue a close() on the
connection after making changes and not explicitly committing.
Color me very, very confused.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5.23 dbcp not honoring autocommit = false?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
On 10/11/17 5:21 PM, Chris Cheshire wrote:
> Working on a migration from 7 to 8.5, and in it I am now using the
> tomcat dbcp, instead of apache commons dbcp.> I have found that
> with no other changes to the db code (except the factory param for
> the resource), it is working fine other than there is an implicit
> commit happening when I close a connection, even with autocommit
> turned off in mysql config, resource config AND in my code.
Your complaint is very close to my heart, here. <3
Back in 2003 or so, I posted roughly this exact question to this
mailing list with a little less ... diplomacy, shall we say?
> try { this.dbConn = this.dataSource.getConnection();
> this.dbConn.setAutoCommit(false);
> this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMIT
TED);
>
>
}
> catch (SQLException ex) { throw new DAOException("unable to get
> database connection", ex); }
I'll bet you've had this problem for a really long time, but just
didn't notice it until now.
The core problem is that you have autocommit=false in your
configuration and autocommit=true in your code. If an exception occurs
and you don't rollback the transaction, the connection pool will reset
all of the settings to your configured settings (including
autocommit=true). Setting autocommit=true when autocommit=false
commits the transaction, which is SUPER surprising to anyone who
hasn't read the Javadoc[1]
Technically, this happens whether you encounter an exception or not,
but it's fairly rare to have code that intentionally does this:
conn.setAutoCommit(false);
// UPDATE ...;
conn.close();
So, given that this is usually an "exceptional" situation, it's your
exceptions you need to carefully handle. In fact, you need to do more
than you are used to doing.
Have a look at this post I did years later when related questions kept
coming up on the list:
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin
g-pooled-jdbc-connections/
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngMBoACgkQHPApP6U8
pFhdjBAAl2u3lxKhrjKdmtjUgtYp0/gOfTPq7jXjdgZBrkSNh9q6I8dJ6gQOsECV
TkCQ2LH8tAUpuUYWCt7QJRLQPVAuwrzplue1InlTFCS8I1b/WK7vQk93teB4I0Ia
HKaC4RGGtgKgS//PsCRxDdFgo0Hzr+hA+nte1qFytmla8ZRZjimbz5EnWJpNwYoU
XjEjhaF6wdVOHP8zKU9/CIc3XQKC1kfQb9Rodb9SZTpjFDTw12NsBjEXG5evY8XJ
A2PPxHPiRdyyHq2R1MDWGFWdSdCsY4pFq4nvNExEuIuHg1/C+GlGUENLH3MiJNPY
minxeaKykVfmUd2zJvWjxmhrdw8nHT3ThtAHA0BgU7thBCenANFbSBxx7+39Jxg/
eDEW4dEqOP3c/ZvifpMrGxjJ0zXBXDu7Jik4KFEzMWI8oaAl3hSSDwEe7FEJE41Y
lDv+LjcBgDwSHLfTbau+0xJx79wAKTAFY7v7uGujUgDZqWsRG1znyZx+OuZnbWxQ
JSbQSJ3pOMerybeJMuHx1a4y+HwA4t0GtLigeRMeyFvTqqtfCVasr3ONMh22XYIU
OORbLADRwjbqYnswvxRC06FfKvU8AhNwuybt/XzHrTfURuIZWx7GRycMlaEMaUdS
OdWlW6Zf3+fWfUxg05zIX3q2Ug4h2O1zW+ccPOrs5bswE9EEAZM=
=eyik
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 8.5.23 dbcp not honoring autocommit = false?
Working on a migration from 7 to 8.5, and in it I am now using the
tomcat dbcp, instead of apache commons dbcp. I have found that with no
other changes to the db code (except the factory param for the
resource), it is working fine other than there is an implicit commit
happening when I close a connection, even with autocommit turned off
in mysql config, resource config AND in my code.
Resource config :
Only thing changed in that from 7.x to 8.5.x is the factory was
org.apache.commons.dbcp.BasicDataSourceFactory. I am using Connector/J
5.1.44 (latest version).
Getting a connection boils down to this in my code (pieces pulled out
of factories and other classes)
(Support class in web code)
public static DataSource getDataSource() {
try {
return (DataSource)new
InitialContext().lookup("java:comp/env/" +
ServletContextParameters.getDatabaseResourceName());
}
catch (NamingException ex) {
throw new RuntimeException("unable to find datasource", ex);
}
}
(DAO Factory implementation)
public MySQLDAOFactoryImpl(@NotNull DataSource dataSource) {
this.dataSource = dataSource;
try {
this.dbConn = this.dataSource.getConnection();
this.dbConn.setAutoCommit(false);
this.dbConn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
}
catch (SQLException ex) {
throw new DAOException("unable to get database connection", ex);
}
}
@Override
public void close() {
try {
if (this.dbConn != null) {
this.dbConn.close();
}
}
catch (SQLException ex) {
throw new DAOException("error closing database connection", ex);
}
}
If I do
daoFactory = new MySQLDAOFactoryImpl(getDataSource());
// update #1
daoFactory.commit()
// update #2
daoFactory.close();
then update #2 is being committed.
If I put in this in the close() method of my DAO Factory
if (!this.dbConn.getAutoCommit()) {
this.dbConn.rollback();
}
before the close() call, then update #2 is correctly not getting committed.
I looked back through the recent tomcat changelogs, and found a
reference to https://bz.apache.org/bugzilla/show_bug.cgi?id=61425
under the 8.5.21 release which looks like it might be addressing this
problem. However, when I download the source for 8.5.23, there is no
org.apache.tomcat.jdbc directory so I can't dive in there.
Anyone else experienced this? Hopefully I am just missing something obvious.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.23 - Nio2 Connector - Error reading request, ignored
On Thu, Oct 5, 2017 at 7:11 PM, Eirik Lykken wrote: > > 05-Oct-2017 17:13:32.535 SEVERE > [https-openssl-nio2-94.229.64.230-443-exec-19701] > org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error > reading request, ignored > java.lang.IllegalStateException > at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2Upgrad > eHandler.java:1314) > at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2Upgrad > eHandler.java:1290) > at org.apache.coyote.http2.Http2Parser.readConnectionPreface(Ht > tp2Parser.java:574) > at org.apache.coyote.http2.Http2UpgradeHandler.init(Http2Upgrad > eHandler.java:243) > at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch( > Http2UpgradeHandler.java:310) > at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.di > spatch(UpgradeProcessorInternal.java:54) > at org.apache.coyote.AbstractProcessorLight.process(AbstractPro > cessorLight.java:53) > at org.apache.coyote.AbstractProtocol$ConnectionHandler.process > (AbstractProtocol.java:868) > at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRu > n(Nio2Endpoint.java:1693) > at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro > cessorBase.java:49) > at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(Ab > stractEndpoint.java:946) > at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteC > ompletionHandler.completed(SecureNio2Channel.java:115) > at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteC > ompletionHandler.completed(SecureNio2Channel.java:108) > at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) > at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) > at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixA > synchronousSocketChannelImpl.java:736) > at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousS > ocketChannelImpl.java:382) > at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousS > ocketChannelImpl.java:399) > at java.nio.channels.AsynchronousSocketChannel.write(Asynchrono > usSocketChannel.java:577) > at org.apache.tomcat.util.net.SecureNio2Channel.handshakeIntern > al(SecureNio2Channel.java:273) > at org.apache.tomcat.util.net.SecureNio2Channel.handshake(Secur > eNio2Channel.java:204) > at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRu > n(Nio2Endpoint.java:1671) > at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketPro > cessorBase.java:49) > at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(Ab > stractEndpoint.java:946) > at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCo > mpletionHandler.completed(SecureNio2Channel.java:98) > at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCo > mpletionHandler.completed(SecureNio2Channel.java:91) > at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) > at sun.nio.ch.Invoker$2.run(Invoker.java:218) > at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousCh > annelGroupImpl.java:112) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool > Executor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo > lExecutor.java:624) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.r > un(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:748) > I think the state of the handshake is most likely ok despite the weird looking stack. The code doing blocking SSL reads is complex also, it would be returning 0 bytes for a blocking read in this case. To examine the issue it would need to be reproduced. Although it might simply be an IO error that doesn't get reported as it should and you see that stack instead (but the result is then the same). > > This is our current Connector configuration: > > protocol="org.apache.coyote.http11.Http11Nio2Protocol" > SSLEnabled="true" > maxThreads="1500" acceptCount="5000" scheme="https" secure="true" > defaultSSLHostConfigName="xxx" > hostName="xxx" > connectionTimeout="7" > URIEncoding="UTF-8" > server="Apache" > enableLookups="false" > compression="on" compressionMinSize="2048" > compressableMimeType="text/html,text/xml,text/csv,text/css,t > ext/javascript,text/html,text/plain,application/javascript,a > pplication/x-javascript" > sslImplementationName="org.apache.tomcat.util.net.openssl.Op > enSSLImplementation" > > > readTimeout="7" writeTimeout="7" maxConcurrentStreams="400" > maxConcurrentStreamExecution="400"/> > maxConcurrentStreamExecution="400" that's way too much, don't do that. > We have experimented with different parameters of the Http2Protocol > connector to improve performance and control the leak with > Http11NioProtocol connector but the exceptions are there with any of the > value
Tomcat 8.5.23 - Nio2 Connector - Error reading request, ignored
Dear All, We are running Tomcat 8.5.23 production server on a CentOS 6.9 machine, Oracle JVM 1.8.0_144, and OpenSSL 1.1.0f. The server hosts a web application where almost all the traffic is https. We used to have a Http11NioProtocol connector with Java SSL using HTTP 1.1 but we switched to Http2Protocol upgrade because of problems with Apple clients (KeepAlive timeout, server dropped the connection, etc..). We also switched to OpenSSL for ALPN. Since then we have had several problems with the different connectors, all of them tested with Tomcat 8.5.16, 8.5.20 and 8.5.23. - Http11NioProtocol has a memory leak, we experienced the same behaviour as this bug https://bz.apache.org/bugzilla/show_bug.cgi?id=57546 so we have to restart the server regularly. - Http11AprProtocol runs fine but the JVM crashes unexpectedly with a core dump from time to time. - Http11Nio2Protocol runs fine but some requests are not processed. We have not found a way to reproduce the problem but it happens once every 5 minutes. The server processes 1.13 million requests per day so it's one request failed every 4000 approximately. We can't reproduce the failed requests, but some crawling tools report them as if the server failed to respond (no status code) This is the exception we get: 05-Oct-2017 17:13:32.535 SEVERE [https-openssl-nio2-94.229.64.230-443-exec-19701] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading request, ignored java.lang.IllegalStateException at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1314) at org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1290) at org.apache.coyote.http2.Http2Parser.readConnectionPreface(Http2Parser.java:574) at org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:243) at org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:310) at org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1693) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:115) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:108) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736) at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382) at sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399) at java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577) at org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:273) at org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204) at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1671) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:98) at org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:91) at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at sun.nio.ch.Invoker$2.run(Invoker.java:218) at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) This is our current Connector configuration: We have experimented with different parameters of the Http2Protocol connector to improve performance and control the leak with Http11NioProtocol connector but the exceptions are there with any of the values or removing the extra parameters. We also tried Tomcat/9.0.0.M
[ANN] Apache Tomcat 8.5.23 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.23. Tomcat 8.x users should normally be using 8.5.x releases in preference to 8.0.x releases. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new features pulled forward from the 9.0.x branch. The notable changes since 8.5.20 include: - Fix CVE-2017-12617 - Add ExtractingRoot, a new WebResourceRoot implementation that extracts JARs to the work directory for improved performance when deploying packed WAR files. - Additional capabilities for the CGI Servlet. Based on patches provided by jm009. - Added support for the OpenSSL SSL_CONF API. To support this the minimum required Tomcat Native version is 1.2.14. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
