Re: Tomcat native tc and a custom OpenSSL engine for ECDH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Piyush, On 8/6/18 7:37 PM, Piyush K wrote: > Hi Christopher, > > I am using my own custom OpenSSL engine that I wrote for elliptical > curve doggie Hellman (ECDH) > > I am setting the SSLEngine to my engine name in the Listener in the > tomcat configuration file (conf/server.xml) > > But looks like the engine is not being set in the function call to > SSL_dh_GetParamFromFile(...) which returns the pointer to DH (in > file tomcat-native-1.2.16-arc/native/src/sslcontext.c) , I don't > believe the engine is being set (as SSL_dh_GetParamFromFile(...) > calls PEM_read_bio_DHparams(...). However SSL_dh_GetParamFromFile > doesn't set the ENGINE * parameter inside the structure for DH > (aliased as dh_st). Because ENGINE * is not set the default OpenSSL > implementation for ECDH is getting called. Please correct me if I > am wrong, Just for confirmation, please post your and configurations, plus the relevant log file lines from catalina.out (or similar) that show the APRLifecycleListener starting up. - -chris >> On Aug 4, 2018, at 8:49 AM, Christopher Schultz >> wrote: >> > Piyush, > On 8/3/18 2:52 PM, Piyush K wrote: Dear tomcat community, I have a question - I am using tomcat and OpenSSL (with apr and tomcat= -native-1.2.16). Versions are as follows :- apr-1-config 1.5.2 tomcat-native-1.2.16 OpenSSL 1.1.0 Tomcat 8.5.31 This works fine with my custom OpenSSL 1.1.0 installation.=20 Next I wrote my own custom OpenSSL engine for ECDHE (ephemeral even), howeve= r tomcat native still seems to make calls to the default ECDHE engine that c= omes with OpenSSL (instead of using mine, even though I compiled, tested and= installed the needed shared object in the relevant directory for OpenSSL e= ngines shared objects). Does the tomcat native code needs to be modified to support a custom OpenSSL= engine for ECDHE.=20 If yes, can I get some help on which places and which files one needs to mod= ify (I have looked at the file sslcontext.c but it is bit very clear on how t= o tie your custom OpenSSL ECDHE engine with the EC keys being generated) > > > Do you have you own "engine" or are you just replacing one of the > cipher suites? > > What does your Tomcat configuration and APR > look like? > > You probably have to set the "SSLEngine" attribute to identify > your custom engine. > > http://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#APR_Life cy > > cle_Listener_-_org.apache.catalina.core.AprLifecycleListener > > -chris >> >> - >> >> 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 > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltpDK0ACgkQHPApP6U8 pFhoGg//Y85TkRhY9IZT692O6hNYxOTnLhzuqmS86pF5oMp3EQQtvYwAUtXt6IRj HNhbyZUzqyY+ISIxTFdRHMzGdahtariAYLUB3ZjiMCKrcVC1dI7+jERzlh8oBiLG ENQdGdR+6RsTMY3o1Kk6QAHXLKQRyVP+ASlfQajrey7TU0ivu5VqjsIcHFBZhQwU hRuruSyDH6Prdx3VvuWA400sgb27ogriPBXWGgG6OmIpeH+maAW+yPyJFC+McP8N fmEKo5inbo9NcL+8ENeAEU2HbvN/xTZWQMpJxKqMDEi3f7yrLGAuDWJX8W0JduVE jm9+HRppl/LeSjLDGpEIqfuCxPBYuZK1r3ZT11sVzVOM23lRHM5ynXFAdw555FfF YOpC+4CZpIp7aKahkgjWhGfsF3knuaXmadKIJ7J5QKlmstLVpf++QtDxbLSp4bzT Uh3L0oLkEFGsOIgfOiOXgK94gS143e+lVLacqMBw28VRptJiZbcSMgBCbEKyo4Cb obxrKm8lnYraj/EkW+HDQNwl/baFYDQx2GzkGyz9YXDraE/uEKbCc3//xyMm7AQH DhDHZ/qP3s+owQ84qS4LHIY+Ea8KZIetGrUlhudD67aiU6rv1c/Rm6zoxEbriaiG pEikGIGXg4Zljnz9YcX49Lx20/akwwNxiNErXjUCjKCdtY6ZMCw= =f6yb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IIS Connector Not Working
Hi,
The fact that it is working on one machine and not the other then have you
rules out all of the NON IIS Connector differences (ex. Machine Operating
Systems, Privileges, etc..)?
- Louis
-Original Message-
From: George S. [mailto:geor...@mhsoftware.com]
Sent: Monday, August 06, 2018 9:51 PM
To: Tomcat Users List
Subject: Re: IIS Connector Not Working
- - - external message, proceed with caution - - -
One more bit of information:
if I go to :
http://hostname/jakarta/
on the working machine, I get a 403-Forbidden.
If I go to the same url on the non-working machine, I get a directory
listing of the files in the directory that the "jakarta" application
points to.
On 8/6/2018 7:38 PM, George S. wrote:
> I'm having a rough time getting the IIS Connector working on a
> specific machine. I'm getting a 404 error when I request a file in my
> Tomcat application. I'm using version 1.2.43 of the ISAPI Redirector
> on Windows Server 2016 with IIS 10.0.
>
> I've carefully checked, and re-checked, and followed the directions. I
> can get it to work on a machine with a scratch install of Microsoft
> Windows Server 2016, but I can't get it to work on another machine.
>
> I'm not getting an isapi_redirect.log file in the
> ${catalina.base}\logs directory. I've checked and re-checked the
> permissions. I've tried running the "jakarta" application under an App
> pool that runs as "Network Service" and under "DefaultAppPool". For
> DefaultAppPool, I set permissions on the directory for "IIS
> AppPool\DefaultAppPool". In neither case do I get an ISAPI Redirect
> log. I know from experience that not getting an isapi_redirect.log
> file usually indicates a permission problem but I've beaten that
> silly. I've verified my URIWorkerMap.properties and Workers.properties
> files exist as expected.
>
> I tried enabling Windows Tracing for 404 requests, and the log files
> aren't getting created by IIS for the failed request.
>
> Does anyone have any ideas? Is there another way to integrate with IIS
> via reverse proxy?
>
> I would REALLY appreciate any ideas.
>
>
--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may
contain information that is confidential, proprietary or exempt from
disclosure. If you are not the intended recipient, please contact the sender
immediately. Unauthorized use or distribution is prohibited and may be unlawful.
Re: IIS Connector Not Working
One more bit of information:
if I go to :
http://hostname/jakarta/
on the working machine, I get a 403-Forbidden.
If I go to the same url on the non-working machine, I get a directory
listing of the files in the directory that the "jakarta" application
points to.
On 8/6/2018 7:38 PM, George S. wrote:
I'm having a rough time getting the IIS Connector working on a
specific machine. I'm getting a 404 error when I request a file in my
Tomcat application. I'm using version 1.2.43 of the ISAPI Redirector
on Windows Server 2016 with IIS 10.0.
I've carefully checked, and re-checked, and followed the directions. I
can get it to work on a machine with a scratch install of Microsoft
Windows Server 2016, but I can't get it to work on another machine.
I'm not getting an isapi_redirect.log file in the
${catalina.base}\logs directory. I've checked and re-checked the
permissions. I've tried running the "jakarta" application under an App
pool that runs as "Network Service" and under "DefaultAppPool". For
DefaultAppPool, I set permissions on the directory for "IIS
AppPool\DefaultAppPool". In neither case do I get an ISAPI Redirect
log. I know from experience that not getting an isapi_redirect.log
file usually indicates a permission problem but I've beaten that
silly. I've verified my URIWorkerMap.properties and Workers.properties
files exist as expected.
I tried enabling Windows Tracing for 404 requests, and the log files
aren't getting created by IIS for the failed request.
Does anyone have any ideas? Is there another way to integrate with IIS
via reverse proxy?
I would REALLY appreciate any ideas.
--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
IIS Connector Not Working
I'm having a rough time getting the IIS Connector working on a specific
machine. I'm getting a 404 error when I request a file in my Tomcat
application. I'm using version 1.2.43 of the ISAPI Redirector on Windows
Server 2016 with IIS 10.0.
I've carefully checked, and re-checked, and followed the directions. I
can get it to work on a machine with a scratch install of Microsoft
Windows Server 2016, but I can't get it to work on another machine.
I'm not getting an isapi_redirect.log file in the ${catalina.base}\logs
directory. I've checked and re-checked the permissions. I've tried
running the "jakarta" application under an App pool that runs as
"Network Service" and under "DefaultAppPool". For DefaultAppPool, I set
permissions on the directory for "IIS AppPool\DefaultAppPool". In
neither case do I get an ISAPI Redirect log. I know from experience that
not getting an isapi_redirect.log file usually indicates a permission
problem but I've beaten that silly. I've verified my
URIWorkerMap.properties and Workers.properties files exist as expected.
I tried enabling Windows Tracing for 404 requests, and the log files
aren't getting created by IIS for the failed request.
Does anyone have any ideas? Is there another way to integrate with IIS
via reverse proxy?
I would REALLY appreciate any ideas.
--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
Re: Tomcat native tc and a custom OpenSSL engine for ECDH
I meant "Diffie Hellman", my iPhone spell checker has a mind of its own :) Sent from my iPhone > On Aug 6, 2018, at 4:37 PM, Piyush K wrote: > > Hi Christopher, > > I am using my own custom OpenSSL engine that I wrote for elliptical curve > doggie Hellman (ECDH) > > I am setting the SSLEngine to my engine name in the Listener in the > tomcat configuration file (conf/server.xml) > > But looks like the engine is not being set in the function call to > SSL_dh_GetParamFromFile(...) which returns the pointer to DH (in file > tomcat-native-1.2.16-arc/native/src/sslcontext.c) , I don't believe the > engine is being set (as > SSL_dh_GetParamFromFile(...) calls PEM_read_bio_DHparams(...). However > SSL_dh_GetParamFromFile doesn't set the ENGINE * parameter inside the > structure for DH (aliased as dh_st). Because ENGINE * is not set the default > OpenSSL implementation for ECDH is getting called. >Please correct me if I am wrong, > > Regards, > Piyush > > Sent from my iPhone > >> On Aug 4, 2018, at 8:49 AM, Christopher Schultz >> wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Piyush, >> >>> On 8/3/18 2:52 PM, Piyush K wrote: >>> >>> Dear tomcat community, >>> >>> I have a question - I am using tomcat and OpenSSL (with apr and >>> tomcat= -native-1.2.16). Versions are as follows :- apr-1-config >>> 1.5.2 tomcat-native-1.2.16 OpenSSL 1.1.0 Tomcat 8.5.31 >>> >>> This works fine with my custom OpenSSL 1.1.0 installation.=20 Next >>> I wrote my own custom OpenSSL engine for ECDHE (ephemeral even), >>> howeve= r tomcat native still seems to make calls to the default >>> ECDHE engine that c= omes with OpenSSL (instead of using mine, even >>> though I compiled, tested and= installed the needed shared object >>> in the relevant directory for OpenSSL e= ngines shared objects). >>> Does the tomcat native code needs to be modified to support a >>> custom OpenSSL= engine for ECDHE.=20 If yes, can I get some help on >>> which places and which files one needs to mod= ify (I have looked >>> at the file sslcontext.c but it is bit very clear on how t= o tie >>> your custom OpenSSL ECDHE engine with the EC keys being generated) >> >> >> Do you have you own "engine" or are you just replacing one of the >> cipher suites? >> >> What does your Tomcat configuration and APR >> look like? >> >> You probably have to set the "SSLEngine" attribute to identify your >> custom engine. >> >> http://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#APR_Lifecy >> cle_Listener_-_org.apache.catalina.core.AprLifecycleListener >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltlyvAACgkQHPApP6U8 >> pFjFZQ//QLHn9And0bqhlz/XQ01cwNA4ClpoCcMwd7t9DYsgLx26vRksIYCWiqIp >> sUUZTlEJ4HDroKZcH4AkxPUER0Y1i0aC3Var4UfgNaojDH0upsX2mrm5P4JXHuXb >> 6KiRkDfnRrkNAXoOiVFiaP/gK/jMtBDzPOgAGuOpHCDyaxXUCEQK+U0krPbslsLO >> 3rsQuN/R+qj7DpR9j61Mpj4R4tCq+nKLcUH9xj6NlKfMTSkwaICYerjV1eBD0WAE >> TI6u7Kd8gB8GLdug8kwct21jxi1vpspaOx5lxy9fe0YwAvvjz2xyT5Z+wlG6L+pT >> 9e/VGI3wzvSaUP3yk2S3lw6cVmnuGRsODorDgmvzE3XptFl++uPM76QxlktChKjd >> NsL25/EsxcPCSEiRUnevCPcnoJu4Dl/PdmNOZrd0oVuyRCaSFqOd4cLZ0mwvAjPE >> TXQ7JKeGwu1MvmHPVoQ8J4uxIwwxhwWV/WGx9FdURjkGjBC9E6VMCi1D3rK2T3U3 >> LeZhzf9ZKWyI3BFfFZtcEgMZe1lQGu9d8ck4fAgNaFn50v+rDdCGFnfdZhu1htXR >> +JgzXXwyJMZJQuTDEMrr9xwZxsJjPx2RfSYTyY6iLeRfCsvxpi6gC8AsKKlsL7lV >> RrWaOfU6sLJA4usrUtDu5fm54UjleW7ZfWvzhO1Kdhde3B9QjEQ= >> =0b3l >> -END PGP SIGNATURE- >> >> - >> 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 native tc and a custom OpenSSL engine for ECDH
Hi Christopher, I am using my own custom OpenSSL engine that I wrote for elliptical curve doggie Hellman (ECDH) I am setting the SSLEngine to my engine name in the Listener in the tomcat configuration file (conf/server.xml) But looks like the engine is not being set in the function call to SSL_dh_GetParamFromFile(...) which returns the pointer to DH (in file tomcat-native-1.2.16-arc/native/src/sslcontext.c) , I don't believe the engine is being set (as SSL_dh_GetParamFromFile(...) calls PEM_read_bio_DHparams(...). However SSL_dh_GetParamFromFile doesn't set the ENGINE * parameter inside the structure for DH (aliased as dh_st). Because ENGINE * is not set the default OpenSSL implementation for ECDH is getting called. Please correct me if I am wrong, Regards, Piyush Sent from my iPhone > On Aug 4, 2018, at 8:49 AM, Christopher Schultz > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Piyush, > >> On 8/3/18 2:52 PM, Piyush K wrote: >> >> Dear tomcat community, >> >> I have a question - I am using tomcat and OpenSSL (with apr and >> tomcat= -native-1.2.16). Versions are as follows :- apr-1-config >> 1.5.2 tomcat-native-1.2.16 OpenSSL 1.1.0 Tomcat 8.5.31 >> >> This works fine with my custom OpenSSL 1.1.0 installation.=20 Next >> I wrote my own custom OpenSSL engine for ECDHE (ephemeral even), >> howeve= r tomcat native still seems to make calls to the default >> ECDHE engine that c= omes with OpenSSL (instead of using mine, even >> though I compiled, tested and= installed the needed shared object >> in the relevant directory for OpenSSL e= ngines shared objects). >> Does the tomcat native code needs to be modified to support a >> custom OpenSSL= engine for ECDHE.=20 If yes, can I get some help on >> which places and which files one needs to mod= ify (I have looked >> at the file sslcontext.c but it is bit very clear on how t= o tie >> your custom OpenSSL ECDHE engine with the EC keys being generated) > > > Do you have you own "engine" or are you just replacing one of the > cipher suites? > > What does your Tomcat configuration and APR > look like? > > You probably have to set the "SSLEngine" attribute to identify your > custom engine. > > http://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#APR_Lifecy > cle_Listener_-_org.apache.catalina.core.AprLifecycleListener > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltlyvAACgkQHPApP6U8 > pFjFZQ//QLHn9And0bqhlz/XQ01cwNA4ClpoCcMwd7t9DYsgLx26vRksIYCWiqIp > sUUZTlEJ4HDroKZcH4AkxPUER0Y1i0aC3Var4UfgNaojDH0upsX2mrm5P4JXHuXb > 6KiRkDfnRrkNAXoOiVFiaP/gK/jMtBDzPOgAGuOpHCDyaxXUCEQK+U0krPbslsLO > 3rsQuN/R+qj7DpR9j61Mpj4R4tCq+nKLcUH9xj6NlKfMTSkwaICYerjV1eBD0WAE > TI6u7Kd8gB8GLdug8kwct21jxi1vpspaOx5lxy9fe0YwAvvjz2xyT5Z+wlG6L+pT > 9e/VGI3wzvSaUP3yk2S3lw6cVmnuGRsODorDgmvzE3XptFl++uPM76QxlktChKjd > NsL25/EsxcPCSEiRUnevCPcnoJu4Dl/PdmNOZrd0oVuyRCaSFqOd4cLZ0mwvAjPE > TXQ7JKeGwu1MvmHPVoQ8J4uxIwwxhwWV/WGx9FdURjkGjBC9E6VMCi1D3rK2T3U3 > LeZhzf9ZKWyI3BFfFZtcEgMZe1lQGu9d8ck4fAgNaFn50v+rDdCGFnfdZhu1htXR > +JgzXXwyJMZJQuTDEMrr9xwZxsJjPx2RfSYTyY6iLeRfCsvxpi6gC8AsKKlsL7lV > RrWaOfU6sLJA4usrUtDu5fm54UjleW7ZfWvzhO1Kdhde3B9QjEQ= > =0b3l > -END PGP SIGNATURE- > > - > 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: End of Support for Tomcat versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gaurav, On 8/6/18 9:47 AM, gaurav.kuma...@wipro.com wrote: > Hi Team , > > Could you please let us know End of Support/Life for the below > mentioned Tomcat Version: > > Tomcat 7.0 Tomcat 8.5 Tomcat 9.0 > > We want to use it with RHEL 7.4 OS . Please let me know if you > need any further info to answer the query. As others have said, all continue to be supported and should be for the foreseeable future. My recommendation would be to move to 8.5 or 9.0 if you have not already done so. Tomcat 7 isn't officially in "maintenance mode" but some significant changes were made between 8.0 and 8.5 so the frequency of back-ports for improvements made to 9.0/8.5 are going to become less and less frequent for Tomcat 7. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltouWAACgkQHPApP6U8 pFifgg//Ug6QqUE8lsAqmDqOFQIrrhls+cZn/7ulkseuXVsBgTlOJJ2zqTPOrjqn GOqFDqhjmKOULy+d/x3QtF2nkC4yjlNxALFuDmX8fpWtlRC7jg74aYhCLVHITS52 il3PNp9QQa1ajcyEA6gPUPWGT3mNIVVB1pB5cP8NLP0Kv2yaYKUQqDBSLqhfaKZ1 UMB9JKhGjXOjtoCwADqYPJFJdsZwreV2LqvmdZ0yxAfpn+ZUVQXTYkG2ED01xO7W cy+QUdIpqOwMKkrR3dA7cx2hiXclHVKi5LR1xVVtZaVMnA5sErS6EVVR40fd3cdo yAL6Ei/zp2kna+c7qyMlkas2BK6tGvrz6aEtuIRm1NYPRAm/w9B9XIrr0sEeN4as WW+DcKtuH8APdjLj3RNS4ZVnIR9q54EYe83sc5m+4yZxLvBliMkqEeWuDI2a2741 /BSzHw65CklTxlhvJUWb5dLPer+SJcdn6mFGeE8O0xefIj/bdlD4ZN0Fki1qgKnf a48CxL16CFSJKGCMdG3r6Hzt4GXmx8GarbaeU3fqa6sSxuQNWpE/4qmAtBlWDFLw HDdFrzm2LPICECDECsimnYsm6J1SkjDSq4a/lmPmD8RcISvXLcyQE3+Sm3e8SE9I WREn1jtElj6sD8dpGnIRGbvLIfa+8dG4iTJVy9O3VJAbi1lADJg= =D+ra -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.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
On 06/08/2018 21:05, Chrifister wrote: I'm still confused as to why the exceptions never made it to catalina.out? It depends where the problem occurs. If it occurs in application code (e.g. inside a servlet of filter) then Tomcat will try and log it in most specific log file (host or webapp) that is available. You can change this in logging.properties. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
I may have found the problem and solution. We went back and had a look at
all the logs, not just catalina.out. There was a localhost log made by
Tomcat and in there was a number of exceptions from when the application
was in that weird state. The exceptions were as follows:
java.io.IOException: Broken pipe
java.sql.SQLException: Connection has already been closed.
org.hibernate.TransactionException: JDBC begin transaction failed:
org.hibernate.TransactionException: Already have an associated managed
connection
This last one repeats every second or so until the application is
restarted. This led me to a custom request filter that came from a book
about Hibernate, specifically a section about transaction management. It
says to create a filter and to wrap the transaction around the filter
chain. The code in the filter is as follows:
Session session = HibernateSessionFactory.getSession();
Transaction tx = session.beginTransaction();
try {
chain.doFilter(request, response);
tx.commit();
session.close();
} catch (Throwable ex) {
try {
if (tx.isActive()) {
tx.rollback();
session.close();
}
} catch(Throwable rbEx) {
rbEx.printStackTrace();
}
throw new ServletException(ex);
}
The first exception about a broken pipe indicates a connection was lost.
This is probably from mobile users losing signal or something. Since the
connection was lost, the connection closes somewhere, somehow. So if the
connection is lost during chain.doFilter(), then when it tries tx.commit(),
it fails because the connection is already closed. This falls to the catch
block and I assume tx.isActive() is false at that point so session.close()
is never called. The next request fails on session.beginTransaction() and
then since we are forever throwing exceptions, session.close() is never
called and the app can no longer fully process requests because it never
makes it to chain.doFilter(). This theory follows the order of the thrown
exceptions in the logs.
I can reproduce the issue locally by adding a breakpoint to an action class
and letting eclipse sit there for a couple of minutes. I assume the JDBC
driver closes the connection because when I resume the application I'm
seeing the same symptoms as the issue we've been having. With the following
updated code, only one exception about the connection already being closed
is thrown, but the application recovers and is still usable. I may still
add a catch for that SqlException and just log a message about connection
lost or something.
Session session = HibernateSessionFactory.getSession();
Transaction tx = session.beginTransaction();
try {
chain.doFilter(request, response);
if (session.isOpen() && tx.isActive())
tx.commit();
} catch (Throwable ex) {
try {
if (session.isOpen() && tx.isActive())
tx.rollback();
} catch (Throwable rbEx) {
rbEx.printStackTrace();
}
throw new ServletException(ex);
} finally {
if (session.isOpen())
session.close();
}
We'll deploy the fix to the two most problematic applications tomorrow and
hopefully we won't see the issue anymore. Thanks guys for all commenting
about the logs. That prompted me to go have a deeper look at everything
Tomcat was logging. I'm still confused as to why the exceptions never made
it to catalina.out?
On Mon, Aug 6, 2018 at 2:25 PM Mark Thomas wrote:
>
>
> On 06/08/2018 16:54, Chrifister wrote:
>
>
>
> > Any help would be greatly appreciated.
>
> No real ideas. Just requests for more information and an observation.
>
> The 500 responses should have triggered stack traces in the logs. Can
> you provide some sample stack traces of the errors you are seeing.
>
> What does a thread dump show?
>
> Are you accessing Tomcat directly or via a reverse proxy such as httpd?
>
> That only one app of several gets into this state while other
> applications work correctly points towards an application issue rather
> than anything else.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: End of Support for Tomcat versions
On 06/08/2018 14:47, gaurav.kuma...@wipro.com wrote: Hi Team , Could you please let us know End of Support/Life for the below mentioned Tomcat Version: Tomcat 7.0 Tomcat 8.5 Tomcat 9.0 Best guess hasn't really changed since this: https://markmail.org/message/5klk3rtf4mb2aacv Very roughly, based on historic data, major releases are supported for around 10 years from first release. The intention is to continue that going forwards but what actually ends up happening will depend on circumstances at the time. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: End of Support for Tomcat versions
On 8/6/2018 7:47 AM, gaurav.kuma...@wipro.com wrote: > Could you please let us know End of Support/Life for the below mentioned > Tomcat Version: > > Tomcat 7.0 > Tomcat 8.5 > Tomcat 9.0 > > We want to use it with RHEL 7.4 OS . Please let me know if you need any > further info to answer the query. Looks like all three of those are still supported. http://tomcat.apache.org/whichversion.html I found additional detail. Probably more than you wanted: 8.0 has reached end of support and is less than two months from complete end of life: https://tomcat.apache.org/tomcat-80-eol.html The Tomcat 8 download page says that end of life has not yet been announced for 8.5, so 8.5 and 9.0 are still good. https://tomcat.apache.org/download-80.cgi The Tomcat 7 and Tomcat 9 download pages don't mention anything about end of life: https://tomcat.apache.org/download-70.cgi https://tomcat.apache.org/download-90.cgi Thanks, Shawn - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
On 06/08/2018 16:54, Chrifister wrote: Any help would be greatly appreciated. No real ideas. Just requests for more information and an observation. The 500 responses should have triggered stack traces in the logs. Can you provide some sample stack traces of the errors you are seeing. What does a thread dump show? Are you accessing Tomcat directly or via a reverse proxy such as httpd? That only one app of several gets into this state while other applications work correctly points towards an application issue rather than anything else. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
Hello Chris, Definitely you have to increase the logging level. If your tomcat instance is using JULI and you suspect from struts perhaps you could try to increase the debugging level of struts in your $CATALINA_BASE/conf/logging.properties: org.apache.struts.level=FINE or FINEST Hope it helps, Luis 2018-08-06 18:08 GMT+02:00 Louis Zipes : > Hi, > Not an answer but just letting you my thinking on where I would look for > additional error messages that might help tell more of the story. > > 1) Any additional information in the individual Java Plugin Logs that tell > more of the story? > > 2) Can you increase the logging on the Tomcat side to try to capture more > of the error? > > 3) What about the SUSE logs themselves? Do they tell you anything? > > Thanks, Louis > > -Original Message- > From: Chrifister [mailto:chrifis...@gmail.com] > Sent: Monday, August 06, 2018 11:54 AM > To: users@tomcat.apache.org > Subject: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a > state where they won't serve random bunch of static resources, 500 errors > > - - - external message, proceed with caution - - - > > > Hi, > > Our current setup is Tomcat 9.0.8 running SuSE Enterprise. This server is > running a dozen web applications built with Struts 1.3.8 with some newer > Spring applications on the horizon. There is a large user base with some > applications seeing heavy usage. Applications are currently using Java 1.7 > and 1.8. > > We were originally running Tomcat 7.x but were having issues with perm gen > maxing out very quickly for unknown reasons but possibly related to a buggy > third party "enterprise-grade" reporting Java library. We had to restart > the server nightly to try and keep perm gen from maxing out. Part of the > reason was this third-party library spawned immortal threads that would > prevent an application from unloading and being garbage collected when a > newer build of an application was deployed (the developers behind it never > expected the library would be run on a server with multiple > applications). So we upgraded Tomcat to 8.5.x first and then to 9.x > recently. This fixed the perm gen issue. > > Our current issue we are having is that for some unknown reason and after > seemingly random lengths of time, an application will get into a state and > will start having issues which results in failed page loads or pages not > loading correctly. According to Chrome's network tab in developer console, > a random bunch of static resources (javascript, css, images) are returning > 500 errors and not being served. Whether the page loads or not depends on > exactly which resources were not returned. Every time you access any page > in that application, another random bunch of resources have 500 errors. > There's no indication in any of Tomcat's log files that an application is > in this state. The application will stay in this unusable state until it is > restarted or the server is restarted. > > We've resorted to once again scheduling the server to restart nightly which > has cut down on the frequency of this happening which hints at this being > related to usage, but it is still happening once a week and sometimes more. > The applications that seem to experience this the most are I believe the > more heavily used applications. > > No Spring application has experienced this issue on our other servers which > leads me to tentatively say that Spring is not affected and/or is not a > cause of the issue but upgrading all applications to Spring is not feasible > at the moment. > > We've tried upgrading Struts in the most frequently affected applications > to 1.3.10 but it did not solve the issue and actually afflicted us with > another issue stemming from a bug in that Struts version. So we had to go > back to 1.3.8. > > I spoke with a couple of people in Tomcat's IRC channel and they seemed to > think it was a third-party library or a problem/race condition between the > Struts and Tomcat servlets. While this may be important information, I have > no idea what to do with it. > > I'm not sure debugging is a possibility because it's a remote server and I > wouldn't even know what to look for. I also can't allow a production > application to remain in this state for very long. > > I can't file a bug report because I can't reproduce it at will and I am > unable to provide thread or heap dumps. > > I have a suspicion it may be caused by that third part library although I > don't see how that library would affect Tomcat's serving of static > resources. > > This issue has never happened to our test server or our local instances of > tomcat. Since I suspect it's related to usage, this is not surprising. > > Any help would be greatly appreciated. > > Chris > --- > CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and > may contain information that is confidential, proprietary or exempt from > disclosure. If you are not the
RE: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
Hi, Not an answer but just letting you my thinking on where I would look for additional error messages that might help tell more of the story. 1) Any additional information in the individual Java Plugin Logs that tell more of the story? 2) Can you increase the logging on the Tomcat side to try to capture more of the error? 3) What about the SUSE logs themselves? Do they tell you anything? Thanks, Louis -Original Message- From: Chrifister [mailto:chrifis...@gmail.com] Sent: Monday, August 06, 2018 11:54 AM To: users@tomcat.apache.org Subject: Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors - - - external message, proceed with caution - - - Hi, Our current setup is Tomcat 9.0.8 running SuSE Enterprise. This server is running a dozen web applications built with Struts 1.3.8 with some newer Spring applications on the horizon. There is a large user base with some applications seeing heavy usage. Applications are currently using Java 1.7 and 1.8. We were originally running Tomcat 7.x but were having issues with perm gen maxing out very quickly for unknown reasons but possibly related to a buggy third party "enterprise-grade" reporting Java library. We had to restart the server nightly to try and keep perm gen from maxing out. Part of the reason was this third-party library spawned immortal threads that would prevent an application from unloading and being garbage collected when a newer build of an application was deployed (the developers behind it never expected the library would be run on a server with multiple applications). So we upgraded Tomcat to 8.5.x first and then to 9.x recently. This fixed the perm gen issue. Our current issue we are having is that for some unknown reason and after seemingly random lengths of time, an application will get into a state and will start having issues which results in failed page loads or pages not loading correctly. According to Chrome's network tab in developer console, a random bunch of static resources (javascript, css, images) are returning 500 errors and not being served. Whether the page loads or not depends on exactly which resources were not returned. Every time you access any page in that application, another random bunch of resources have 500 errors. There's no indication in any of Tomcat's log files that an application is in this state. The application will stay in this unusable state until it is restarted or the server is restarted. We've resorted to once again scheduling the server to restart nightly which has cut down on the frequency of this happening which hints at this being related to usage, but it is still happening once a week and sometimes more. The applications that seem to experience this the most are I believe the more heavily used applications. No Spring application has experienced this issue on our other servers which leads me to tentatively say that Spring is not affected and/or is not a cause of the issue but upgrading all applications to Spring is not feasible at the moment. We've tried upgrading Struts in the most frequently affected applications to 1.3.10 but it did not solve the issue and actually afflicted us with another issue stemming from a bug in that Struts version. So we had to go back to 1.3.8. I spoke with a couple of people in Tomcat's IRC channel and they seemed to think it was a third-party library or a problem/race condition between the Struts and Tomcat servlets. While this may be important information, I have no idea what to do with it. I'm not sure debugging is a possibility because it's a remote server and I wouldn't even know what to look for. I also can't allow a production application to remain in this state for very long. I can't file a bug report because I can't reproduce it at will and I am unable to provide thread or heap dumps. I have a suspicion it may be caused by that third part library although I don't see how that library would affect Tomcat's serving of static resources. This issue has never happened to our test server or our local instances of tomcat. Since I suspect it's related to usage, this is not surprising. Any help would be greatly appreciated. Chris --- CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may contain information that is confidential, proprietary or exempt from disclosure. If you are not the intended recipient, please contact the sender immediately. Unauthorized use or distribution is prohibited and may be unlawful.
Tomcat 8.x-9.x + Struts 1.3.x - Applications will get into a state where they won't serve random bunch of static resources, 500 errors
Hi, Our current setup is Tomcat 9.0.8 running SuSE Enterprise. This server is running a dozen web applications built with Struts 1.3.8 with some newer Spring applications on the horizon. There is a large user base with some applications seeing heavy usage. Applications are currently using Java 1.7 and 1.8. We were originally running Tomcat 7.x but were having issues with perm gen maxing out very quickly for unknown reasons but possibly related to a buggy third party "enterprise-grade" reporting Java library. We had to restart the server nightly to try and keep perm gen from maxing out. Part of the reason was this third-party library spawned immortal threads that would prevent an application from unloading and being garbage collected when a newer build of an application was deployed (the developers behind it never expected the library would be run on a server with multiple applications). So we upgraded Tomcat to 8.5.x first and then to 9.x recently. This fixed the perm gen issue. Our current issue we are having is that for some unknown reason and after seemingly random lengths of time, an application will get into a state and will start having issues which results in failed page loads or pages not loading correctly. According to Chrome's network tab in developer console, a random bunch of static resources (javascript, css, images) are returning 500 errors and not being served. Whether the page loads or not depends on exactly which resources were not returned. Every time you access any page in that application, another random bunch of resources have 500 errors. There's no indication in any of Tomcat's log files that an application is in this state. The application will stay in this unusable state until it is restarted or the server is restarted. We've resorted to once again scheduling the server to restart nightly which has cut down on the frequency of this happening which hints at this being related to usage, but it is still happening once a week and sometimes more. The applications that seem to experience this the most are I believe the more heavily used applications. No Spring application has experienced this issue on our other servers which leads me to tentatively say that Spring is not affected and/or is not a cause of the issue but upgrading all applications to Spring is not feasible at the moment. We've tried upgrading Struts in the most frequently affected applications to 1.3.10 but it did not solve the issue and actually afflicted us with another issue stemming from a bug in that Struts version. So we had to go back to 1.3.8. I spoke with a couple of people in Tomcat's IRC channel and they seemed to think it was a third-party library or a problem/race condition between the Struts and Tomcat servlets. While this may be important information, I have no idea what to do with it. I'm not sure debugging is a possibility because it's a remote server and I wouldn't even know what to look for. I also can't allow a production application to remain in this state for very long. I can't file a bug report because I can't reproduce it at will and I am unable to provide thread or heap dumps. I have a suspicion it may be caused by that third part library although I don't see how that library would affect Tomcat's serving of static resources. This issue has never happened to our test server or our local instances of tomcat. Since I suspect it's related to usage, this is not surprising. Any help would be greatly appreciated. Chris
End of Support for Tomcat versions
Hi Team , Could you please let us know End of Support/Life for the below mentioned Tomcat Version: Tomcat 7.0 Tomcat 8.5 Tomcat 9.0 We want to use it with RHEL 7.4 OS . Please let me know if you need any further info to answer the query. BR// Gaurav Sensitivity: Internal & Restricted The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
