Re: tomcat 8.5.23 missing fields: %{cookie} %{Referer} %u in localhost_access_log

[Christopher Schultz]

-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

[Mark Thomas]

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

Re: tomcat 8.5.23 can not modify maxconcurrentstream setting

[Helena Carbajo]

> 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).
> >>
> >>
> >>
> >> I'd be grateful if someone c

Re: tomcat 8.5.23 can not modify maxconcurrentstream setting

[Mark Thomas]

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

RE: tomcat 8.5.23 can not modify maxconcurrentstream setting

[Helena Carbajo]

>> 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

[Mark Thomas]

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

Re: [External] RE: Tomcat 8.5.23

[Christopher Schultz]

-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

[Lawrence Lim]

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 <Lawrence.Lim@e
> 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 <lawrence@enbridge.com>
> > 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

Re: [External] RE: Tomcat 8.5.23

[Felix Schumacher]

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 <Lawrence.Lim@e
> 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 <lawrence@enbridge.com>
> > 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 
> &

Re: Tomcat 8.5.23

[Igor Cicimov]

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

[Lawrence Lim]

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 
<lawrence@enbridge.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 <lawrence@enbridge.com>
>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

[Felix Schumacher]

Am 15. Februar 2018 19:25:24 MEZ schrieb Lawrence Lim 
<lawrence@enbridge.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 <lawrence@enbridge.com>
>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

[Bauer, Margaret M (Peggy)]

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
> > <lawrence@enbridge.com> 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 <lawrence@enbridge.com> 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.
> >> 
> >> 
> >>
> >> -
> >>
> >

Re: [E] RE: Tomcat 8.5.23

[Christopher Schultz]

-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
> <lawrence@enbridge.com> 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 <lawrence@enbridge.com> 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

[Bauer, Margaret M (Peggy)]

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 <lawrence@enbridge.com>
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 <lawrence@enbridge.com>
> 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

[Lawrence Lim]

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 <lawrence@enbridge.com>
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

[Satish Chhatpar 02]

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.

Re: TomCat 8.5.23 application not responding

[DBolken]

From:   Christopher Schultz <ch...@christopherschultz.net>
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

[Christopher Schultz]

-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

Re: Tomcat 8.5.23 Initialization PRNG/SSL

[Christopher Schultz]

-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]

[Christopher Schultz]

-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 

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

[tomcat]

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]

[Bob Hall]

 > 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]

[tomcat]

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

[tomcat]

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

Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

[Chris Cheshire]

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 

Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

[Christopher Schultz]

-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?

[Christopher Schultz]

-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 

Re: tomcat 8.5.23 dbcp not honoring autocommit = false?

[Chris Cheshire]

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?

[Keiichi Fujino]

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=utf8useSSL=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?

[Chris Cheshire]

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?

[Christopher Schultz]

-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?

[Chris Cheshire]

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?

[Chris Cheshire]

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?

[Christopher Schultz]

-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

Re: Tomcat 8.5.23 - Nio2 Connector - Error reading request, ignored

[Rémy Maucherat]

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