Re: Tomcat/Java app timezone radomly changes during operation.

2022-11-08 Thread George Sexton
When you say the time is wrong, how do you know this. Are you using a 
DateFormatter?


Are you instantiating one, and re-using it? Could some code re-using a 
DateFormatter be changing the time zone?


On 10/28/2022 8:22 AM, David wrote:

I'll see if I can answer all queries.

The server doesn't migrate, at least not across timezones.  It is a nutanix
virtual though, so migration between hosts locally is possible.

There is a Java app that allows a user to reset their password.   The db is
called to retrieve a generated code for them to use to reset, it also
validates the user hasn't done this more than 3 times since having a valid
login, and sets an expiry for the duration of this code (4hrs).

There is a dbutil Java app that does use SimpleDateFormat, so I will look
into the bug provided.

When the switch happens, it will show that the date being sent to the DB by
the Java reset pw app is sending values in UTC.  It is instant and
precisely on time, since it's +5 hours, and the pw reset is only valid for
4, it breaks this functionality.   The Java app lives in tomcat and is a
subset of the main website app.

We have lower environments where this doesn't occur.  The app code is the
same everywhere,  Java and OS times are stable everywhere as well.

I did notice that stuck valve detection had a lot of hits during one
occurrence, tomcat slowed as connection threads climbed, and the switch to
utc being sent to the db happened at this time.  I was thinking it may be a
db2 contention issue based on this, normally that would cause connections
to back up and tomcat to run out of threads though,  I've never seen it
change cdt to udt.   I'll dig more into the SimpleDateFormat, as it may be
the cause but is triggered by load/db contention.  Lower environments that
don't show the issue don't have much traffic as they are for dev/uat/etc.

Thanks all!
David

On Fri, Oct 28, 2022, 02:51 Konstantin Kolinko 
wrote:


чт, 27 окт. 2022 г. в 18:31, David :

Hi all,

   I've experienced an issue since the morning of the 21st that I'm
hoping to get some direction on for where to look.

   An app uses the date/time to set a timeout for a password reset.
This had been working fine for years and suddenly it failed.  A restart

of

tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1

hr

and now is averaging a 10 minute or so working duration between tomcat
restarts.

 Changing the logging in the app showed that the issue is due to it
sending UTC to the DB while it is broken.  Restarting Tomcat results in

CDT

being sent for a while until randomly it switches again.

RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29

Looking at the changelog since 9.0.29 onwards,
there was the following issue, fixed in 9.0.34 two years ago:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64226
"Tomcat 9 can return HTTP date headers in timezone other than GMT"

Fixed by commit

https://github.com/apache/tomcat/commit/f64a2a7150bff01bca479c7c319b7e8db879df26

It is about how parsing a date time string may affect formatting time
if the same SimpleDateFormat instance is reused. It is triggered by a
client sending a header using a different time zone.


It is unlikely your issue with the database (unless your application
uses Tomcat internal classes such as ConcurrentDateFormat or
FastHttpDateFormat), but it affects HTTP headers generated by Tomcat.

Best regards,
Konstantin Kolinko

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



--
George Sexton
(303) 438 9585 x102
MH Software, Inc.

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



Re: [EXTERNAL EMAIL] FW: Errors in Tomcat logs / application processing

2022-11-08 Thread Niranjan Rao
Please remember to remove any passwords or sensitive data when you post 
on public email lists


On 11/8/22 00:58, Ganesan, Prabu wrote:
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd

Hi Team .

Could you please help with below errors

We have enabled TLS successfully – but after TLS enabled we are facing 
below issues .


Please help us on Priorities

Thanks & Regards,

_Email_CBE.gif

*PrabuGanesan***

*Consultant|MS-Nordics*

capgemini India Pvt. Ltd. | Bangalore **

Contact: +91 8526554535

Email: prabhu.c.gane...@capgemini.com

www.capgemini.com 



*People matter, results count.*

__

*Connect with Capgemini:*


Please consider the environment and do not print this email unless 
absolutely necessary.


Capgemini encourages environmental awareness.

*From:*Morell, Alice 
*Sent:* 07 November 2022 21:33
*To:* DL IN IKANO Middleware 
*Cc:* Thombre, Dipali Rajesh ; 
Nayak, Shruthi ; Khandekar, Preeti 
; Deshmukh, Hemant 
; Phase, Samir 


*Subject:* Errors in Tomcat logs / application processing

Hello!

The error we are facing is:

“SOAP Problems executing transaction LoginApplication via Web Service, 
underlying problem is Error unmarshalling message”


*I want to know if we can solve this by changing the values in the 
context.xml tags. *The hardcoded URL’s.**


As agreed, here are

  * Info on error logs,
  * Screen shots of the errors that the end user is seeing,
  * Sequential steps for TLS on the instances

And

  * Example on the changes made in the files

You can find the error logs generated for these 2 URLs at this location:

/export/home/aloradm/tls/tls2/Test1FrontEnd/

Where the directory called “1” is for what is described under issue 1 
and “2” under issue 2.. 


 1. To replicate current error:

Use a browser with a cleared cache!

Browse to:

tvmdc2linweb001.baf.ikano:7400/PCUKTST1ENV/ikanoRetail/

Press ”Contact Centre” too get this first error:

Press “Click here to log in again” and then the red button that says 
“Contact centre”.


The page is just getting reloaded to same screen again. For each time 
you press the red button, a url pattern of “/contactcentre” is added 
to the path:


In the backend, the logs for my tries is attached in the folder 
ikanoRetailLogin


-- 



-- 



-- 



To replicate current error you need login credentials, so you can only 
view my screen shot for this one:


Use a browser with a cleared cache!

Browse to:


[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.5

2022-11-08 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.5

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.4 include:

- Narrow scope of javax.annotation conversion to Java EE. Pull request
  by Danny Thomas
- Improve manifest handling and conversion performance. Pull request by
  Danny Thomas.


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

Downloads:
http://tomcat.apache.org/download-migration.cgi

Enjoy!

- The Apache Tomcat team


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



Re: FW: Errors in Tomcat logs / application processing

2022-11-08 Thread Christopher Schultz

Prabu,

On 11/8/22 03:58, Ganesan, Prabu wrote:

Could you please help with below errors

We have enabled TLS successfully – but after TLS enabled we are facing 
below issues .

>
> [snip]


The error we are facing is:

“SOAP Problems executing transaction LoginApplication via Web Service, 
underlying problem is Error unmarshalling message”


*I want to know if we can solve this by changing the values in the 
context.xml tags. *The hardcoded URL’s.**


The short answer is "no". The context.xml file configures Tomcat, and 
Tomcat does not use SOAP.


It's entirely possible that your TLS configuration is causing your SOAP 
messages to fail to be unmarshalled, but usually either the TLS 
handshake succeeds and then SOAP takes over, or it fails and SOAP 
doesn't get a chance to do anything.


Perhaps Thomas can help in another part of this thread.

-chris

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



Re: JNDI resourse name value

2022-11-08 Thread Christopher Schultz

Rob,

On 11/7/22 16:40, Rob Sargent wrote:



On 11/7/22 14:26, Christopher Schultz wrote:

Rob,

On 11/7/22 14:09, Rob Sargent wrote:

Are there any semantics to Resourse name attributes?

Or is  no more or less valid 
than 


As far as Tomcat is concerned, it's basically the Wild West.

Some other application servers (usually the "enterprise" ones) are 
super strict about where things go in the JNDI space. It's very common 
to see JDBC connections placed into 
java:comp/env/jdbc/[connection-name] but I think technically you could 
put them just about anywhere.


If you put them somewhere else, someone's gonna say "hey, what the 
heck are you doing that for?" because, well, #conventions.


-chris



Thank you.  Indeed  I use

    Context sgsContext  = (Context) ic.lookup("java:/comp/env");

but I am playing fast and loose with resource names within that 
context.  Is that a foot gun?


Do you mean because you used "java:/comp/env" and I used 
"java:comp/env"? I think the leading slash doesn't matter.


-chris

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



[ANN] Apache Tomcat Native 2.0.2 released

2022-11-08 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 2.0.2 stable.

The key features of this release are:

- Update the minimum supported version of LibreSSL to 3.5.2.
  Based on a #13 provided by orbea.

- The windows binaries in this release have been built with OpenSSL
  3.0.7

The 2.0.x branch is primarily intended for use with Tomcat 10.1.x or 
later but can be used with earlier versions as long as the APR/native 
connector is not used.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library 2.0.x provides an API for using OpenSSL 
for SSL networking with Apache Tomcat.


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