Re: Timestamp Error

[Terence M. Bandoian]

On 8/27/2021 2:31 PM, Jerry Malcolm wrote:


On 8/27/2021 1:30 PM, Mark Eggers wrote:

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data 
truncation: Incorrect datetime value: '1969-12-31 18:00:00.0' for 
column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into 
phpMyAdmin, and it worked.  When I change the date to '2021-08-27 
01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016. But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right 
now,
I don't know what dates are going to work and what dates are 
going to fail.


Am I missing something obvious?  I've never had a SQL statement 
that failed consistently on TC but worked when pasted into 
phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that 
your system is running in Us-Mountain Time, 6 hours behind UTC in 
the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, 
and that your driver is using MDT as your time zone, trying to 
convert NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT 
-> boom, since the minimum allowed TIMESTAMP value is 1970-01-01 
00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't 
good for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my 
dev machine.  However, my production server (Linux) does have the 
timezones all set correctly.  My insert statement has a value of 
"new Timestamp(0).toString()".  On the production server, this 
becomes '1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value? mySQL 
accepts 1969-12-31 18:00:00.0 in the insert statement. mySQL may be 
adjusting the time +6 on my laptop back up the epoch value before 
storing it.  But the situation still remains that the same insert 
statement works on phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 
00:00:00.0' in the insert statement, but works with that value when 
inserted into mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  
Is the driver detecting this and generating the exception?  Or does 
the insert statement get all the way to mySQL and mySQL fails back 
to the driver followed by the driver throwing the exception?


Jerry


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



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/

|Timestamp 
(long time)| 


Constructs a |Timestamp| object using a milliseconds time value.
|time| - milliseconds since January 1, 1970, 00:00:00 GMT. A negative 
number is the number of milliseconds before January 1, 1970, 00:00:00 
GMT.


This says that a timestamp can be before the epoch, no minimum time, 
which agrees with what I'm seeing via phpMyAdmin.  Which means that 
what I'm providing in the sql insert statement should be accepted 
regardless of timezone factors. Seems to me there's a bug in the TC 
driver (??)  And the error message I'm getting says "data truncation", 
which at best is incorrect wording.  Not sure how any truncation could 
occur on a date string that parses to (long)0.  I thought the .0 
fractions of a second on the end of the string could be the cause of 

Re: Timestamp Error

[Christopher Schultz]

Jerry,

On 8/27/21 14:16, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


WAIT. DO NOT DO THIS.

If you want to set a date/time field in the database, use:

ps = conn.prepareStatement("UPDATE ... SET field=? WHERE ...");
ps.setTimestamp(new Timestamp(0));
ps.executeQuery();

Don't convert to String. It's awful. If you use Timestamp directly, the 
driver will figure out all the time zone issues and this shouldn't bite you.


I'm running MariaDB and here's what it has to say about TIMESTAMP fields:

MariaDB [diagnosis]> help timestamp;
Name: 'TIMESTAMP'
Description:
TIMESTAMP

A timestamp. The range is '1970-01-01 00:00:01' UTC to '2038-01-19
03:14:07' UTC. TIMESTAMP values are stored as the number of seconds
since the epoch ('1970-01-01 00:00:00' UTC). A TIMESTAMP cannot
represent the value '1970-01-01 00:00:00' because that is equivalent to
0 seconds from the epoch and the value 0 is reserved for representing
'-00-00 00:00:00', the "zero" TIMESTAMP value.

[...]

So you can't even properly store "0" in your database.

-chris

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

Re: Timestamp Error

[Christopher Schultz]

Jerry,

On 8/27/21 14:16, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value?  mySQL accepts 
1969-12-31 18:00:00.0 in the insert statement.  mySQL may be adjusting 
the time +6 on my laptop back up the epoch value before storing it.  But 
the situation still remains that the same insert statement works on 
phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 00:00:00.0' 
in the insert statement, but works with that value when inserted into 
mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  Is 
the driver detecting this and generating the exception?  Or does the 
insert statement get all the way to mySQL and mySQL fails back to the 
driver followed by the driver throwing the exception?


Connector/J checks the time zone of the server relative to the time zone 
of the java.sql.Timestamp (really java.util.Date) object and adjusts 
accordingly. So if you are using "new Timestamp(0)" in your code, that 
may be the difference. I find it odd that MySQL accepts the literal 1969 
date, though. It's possible you are right and the date is being 
fast-forwarded to UTC so it actually becomes 1970-01-01 00:00:00 by the 
tie the server tries to store it.


If you are storing new Timestamp(0), you are most likely better off 
storing NULL since the beginning of the Epoch is probably not a 
meaningful value for you to store. Then again, if you have 100M rows, 
adding NULLABLE to your table definition may not be on your short-list 
of things to do.


-chris

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

Re: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?

[Christopher Schultz]

Polina,

On 8/26/21 10:48, Polina Georgieva wrote:

Currently the RestCsrfPreventionFilter is responding with 403 response when
the csrf token sent in the request is different from the one stored in the
session.

However except the 403 response code visible in the http access log file,
there’s no indication what happened and why is the error response.

So I think introducing some logs in this filter would be beneficial at
least from two points of view:

1. Troubleshooting

It would be easier to troubleshoot problems with clients that did not
integrate with the csrf prevention mechanism properly or could give more
clues for other situations - for example cases of session invalidation
(done by other filter for example) before the request reaches the filter.
Currently such requests are also responded with 403 though the client seems
to have sent valid session cookie and  csrf token. That’s why I believe it
would be of great help to add log(s) stating:

- if the requested session is found
- if there’s token stored in it
- if there’s token and session cookie sent in the request

without revealing their actual values or other security sensitive data.

And this information could be logged only in cases of 403 responses, i.e.
would appear only when needed.

1. Improve identifying/tracking security related incidents

According to OWASP guidelines it’s recommended to have probable malicious
attacks indicated in the logs to better identify security incidents. For
more details please refer to [1].



If you agree with these ideas, I’ll be happy to propose a patch?


This sounds like a great idea. The RestCsrfPreventionListener and its 
superclass CsrfPreventionListenerBase both have access to a log object 
via the getLogger() method. It would be trivial to:


1. Add logging for whatever situation you'd like to log
2. Configure a logger to direct the output of the CSRF failures wherever 
you'd like


So I think you don't need to worry too much about the logging 
*mechanism* but instead simply add calls to the existing logger.


I was surprised to see *zero* logging in these classes, and adding such 
logging would certainly be a welcome improvement.


-chris

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

Re: Timestamp Error

[Jerry Malcolm]

On 8/27/2021 1:30 PM, Mark Eggers wrote:

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 
01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right 
now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement 
that failed consistently on TC but worked when pasted into 
phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that 
your system is running in Us-Mountain Time, 6 hours behind UTC in 
the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, 
and that your driver is using MDT as your time zone, trying to 
convert NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT 
-> boom, since the minimum allowed TIMESTAMP value is 1970-01-01 
00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't 
good for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the 
timezones all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value?  mySQL 
accepts 1969-12-31 18:00:00.0 in the insert statement.  mySQL may be 
adjusting the time +6 on my laptop back up the epoch value before 
storing it.  But the situation still remains that the same insert 
statement works on phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 
00:00:00.0' in the insert statement, but works with that value when 
inserted into mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  
Is the driver detecting this and generating the exception?  Or does 
the insert statement get all the way to mySQL and mySQL fails back to 
the driver followed by the driver throwing the exception?


Jerry


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



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/

|Timestamp 
(long time)| 


Constructs a |Timestamp| object using a milliseconds time value.
|time| - milliseconds since January 1, 1970, 00:00:00 GMT. A negative 
number is the number of milliseconds before January 1, 1970, 00:00:00 GMT.


This says that a timestamp can be before the epoch, no minimum time, 
which agrees with what I'm seeing via phpMyAdmin.  Which means that what 
I'm providing in the sql insert statement should be accepted regardless 
of timezone factors. Seems to me there's a bug in the TC driver (??)  
And the error message I'm getting says "data truncation", which at best 
is incorrect wording.  Not sure how any truncation could occur on a date 
string that parses to (long)0.  I thought the .0 fractions of a second 
on the end of the string could be the cause of 'truncation'.  However, 
the 6-digit 

Re: Timestamp Error

[Mark Eggers]

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value?  mySQL accepts 
1969-12-31 18:00:00.0 in the insert statement.  mySQL may be adjusting 
the time +6 on my laptop back up the epoch value before storing it.  But 
the situation still remains that the same insert statement works on 
phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 00:00:00.0' 
in the insert statement, but works with that value when inserted into 
mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  Is 
the driver detecting this and generating the exception?  Or does the 
insert statement get all the way to mySQL and mySQL fails back to the 
driver followed by the driver throwing the exception?


Jerry


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



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/



OpenPGP_signature
Description: OpenPGP digital signature

Re: Timestamp Error

[Jerry Malcolm]

On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, 
and it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going 
to fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert 
NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, 
since the minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my dev 
machine.  However, my production server (Linux) does have the timezones 
all set correctly.  My insert statement has a value of "new 
Timestamp(0).toString()".  On the production server, this becomes 
'1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value?  mySQL accepts 
1969-12-31 18:00:00.0 in the insert statement.  mySQL may be adjusting 
the time +6 on my laptop back up the epoch value before storing it.  But 
the situation still remains that the same insert statement works on 
phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 00:00:00.0' 
in the insert statement, but works with that value when inserted into 
mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  Is 
the driver detecting this and generating the exception?  Or does the 
insert statement get all the way to mySQL and mySQL fails back to the 
driver followed by the driver throwing the exception?


Jerry


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

Re: Query regarding maxConnections attribute

[Christopher Schultz]

Srijith,

On 8/27/21 06:50, Srijith Kochunni wrote:

We have a project requirement that we need to scale up to accept very
high number of connections. I understand that setting maxConnections
to -1 will disable the counting of the connections. I just wanted to
know whether there are any performance implications when bumping up
the maxConnections from the default value of 8192 to a very high
number like 65K+.


I would think that at 65k connections, you might end up with other parts
of your system that can't come with such high volumes.

Do you expect 65k *simultaneous* requests? Are these HTTP or HTTP/2
connections, or something like WebSocket where you may have long-lived
connections but maybe not much data crossing those connections?


Will this cause any adverse impact on the functioning of Tomcat.?
We're currently on version 9.0.37


Tomcat will be fine.

It's not clear whether your OS or other resources (memory, data-store,
etc.) will be able to handle it. Also remember that your TCP/IP stack 
may limit the total number of connections on a single socket, and your 
OS (usually) limits the number of open file descriptors.


If you are looking at that kind of load, it makes me think you may want 
to look at scaling horizontally.


-chris

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

Re: Timestamp Error

[Christopher Schultz]

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL error 
on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
Incorrect datetime value: '1969-12-31 18:00:00.0' for column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into phpMyAdmin, and 
it worked.  When I change the date to '2021-08-27 01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016.  But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I have 
to avoid dates that fail, I can probably do that.  But right now,
I don't know what dates are going to work and what dates are going to 
fail.


Am I missing something obvious?  I've never had a SQL statement that 
failed consistently on TC but worked when pasted into phpMyAdmin.


Suggestions?

Thanks.

Jerry




https://dev.mysql.com/doc/refman/5.7/en/datetime.html

When you paste from the logs, you're not pasting what the original 
INSERT command is doing. Therefore, it will work, since the error 
message is giving the minimum date back that is supported by MySQL.


There is a setting in the driver called something like "null means zero 
datetime" which may confuse the heck out of TIMESTAMP columns, which 
expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that your 
system is running in Us-Mountain Time, 6 hours behind UTC in the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, and 
that your driver is using MDT as your time zone, trying to convert NULL 
-> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT -> boom, since the 
minimum allowed TIMESTAMP value is 1970-01-01 00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't good 
for much...


-chris

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

RE: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?

[Jalaj Asher]

That will be a great enhancement to have.

Regards

Jalaj P Asher

-Original Message-
From: Polina Georgieva 
Sent: Thursday, August 26, 2021 10:49 AM
To: Tomcat Users List 
Subject: Improve logging in 
org.apache.catalina.filters.RestCsrfPreventionFilter ?

[You don't often get email from poli.m.georgi...@gmail.com. Learn why this is 
important at http://aka.ms/LearnAboutSenderIdentification.]

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Hello,



Currently the RestCsrfPreventionFilter is responding with 403 response when the 
csrf token sent in the request is different from the one stored in the session.

However except the 403 response code visible in the http access log file, 
there's no indication what happened and why is the error response.

So I think introducing some logs in this filter would be beneficial at least 
from two points of view:

   1. Troubleshooting

It would be easier to troubleshoot problems with clients that did not integrate 
with the csrf prevention mechanism properly or could give more clues for other 
situations - for example cases of session invalidation (done by other filter 
for example) before the request reaches the filter.
Currently such requests are also responded with 403 though the client seems to 
have sent valid session cookie and  csrf token. That's why I believe it would 
be of great help to add log(s) stating:

   - if the requested session is found
   - if there's token stored in it
   - if there's token and session cookie sent in the request

without revealing their actual values or other security sensitive data.

And this information could be logged only in cases of 403 responses, i.e.
would appear only when needed.

   1. Improve identifying/tracking security related incidents

According to OWASP guidelines it's recommended to have probable malicious 
attacks indicated in the logs to better identify security incidents. For more 
details please refer to [1].



If you agree with these ideas, I'll be happy to propose a patch?



Best Regards,

Polina



[1]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcheatsheetseries.owasp.org%2Fcheatsheets%2FLogging_Cheat_Sheet.html%23which-events-to-logdata=04%7C01%7Cjalaj.asher%40eclinicalworks.com%7C6cc1405176314999ce0d08d968a0af18%7C7ce747e48f6d4e0697efa9b76a063808%7C1%7C0%7C637655862166690290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ZKENhmdqWfpNGijcGbHz2usa%2FJzJiq%2FNUtvtN91%2FDBA%3Dreserved=0

CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential 
information belonging to the sender that is legally privileged and proprietary 
and may be subject to protection under the law, including the Health Insurance 
Portability and Accountability Act (HIPAA). If you are not the intended 
recipient of this e-mail, you are prohibited from sharing, copying, or 
otherwise using or disclosing its contents. If you have received this e-mail in 
error, please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or saving 
them. Thank you.

CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential 
information belonging to the sender that is legally privileged and proprietary 
and may be subject to protection under the law, including the Health Insurance 
Portability and Accountability Act (HIPAA). If you are not the intended 
recipient of this e-mail, you are prohibited from sharing, copying, or 
otherwise using or disclosing its contents. If you have received this e-mail in 
error, please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or saving 
them. Thank you.

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

Query regarding maxConnections attribute

[Srijith Kochunni]

Hi,

We have a project requirement that we need to scale up to accept 
very high number of connections. I understand that setting maxConnections to -1 
will disable the counting of the connections. I just wanted to know whether 
there are any performance implications when bumping up the maxConnections from 
the default value of 8192 to a very high number like 65K+.

Will this cause any adverse impact on the functioning of Tomcat.? 
We're currently on version 9.0.37

Thanks,
Srijith.