Hi Chris
*This wasn't the case for httpd for many years. I don't know what itdoes
these days, but it used to reply with a nice "400 Bad Request"error just
like Tomcat is doing. The difference is that httpd has richconfiguration
options to allow you to override that behavior. *
Correct. By
On Thu, Aug 27, 2020 at 4:30 PM Christopher Schultz
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> David,
>
> On 8/27/20 17:14, David wrote:
> > Thank you all for the replies!
> >
> > On Thu, Aug 27, 2020 at 3:53 PM Christopher Schultz
> > wrote:
> >>
> > David,
> >
> > On
On Thu, Aug 27, 2020, 16:16 Christopher Schultz <
ch...@christopherschultz.net> wrote:
[ snip ]
If you want to *kill* the application and it won't shut down on its
> own, SIGKILL is the answer. But that's not a great way to shut down an
> application /in general/ because the application might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 8/27/20 17:14, David wrote:
> Thank you all for the replies!
>
> On Thu, Aug 27, 2020 at 3:53 PM Christopher Schultz
> wrote:
>>
> David,
>
> On 8/27/20 13:57, David wrote:
On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Roger,
On 8/27/20 14:43, Roger Marquis wrote:
> Mark Thomas wrote:
>> Those are all application issues. The application should shut
>> itself down cleanly. Tomcat is complaining because it hasn't.
>
> I don't know Mark, most Java/Tomcat engineers
Thank you all for the replies!
On Thu, Aug 27, 2020 at 3:53 PM Christopher Schultz
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> David,
>
> On 8/27/20 13:57, David wrote:
> > On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
> > wrote:
> >>
> > David,
> >
> > On 8/27/20
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Felix,
On 8/27/20 16:09, Felix Schumacher wrote:
>
> Am 27.08.20 um 19:35 schrieb Christopher Schultz:
>> David,
>>
>> On 8/27/20 10:48, David wrote:
>>> In the last two weeks I've had two occurrences where a single
>>> CentOS 7 production server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 8/27/20 13:57, David wrote:
> On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
> wrote:
>>
> David,
>
> On 8/27/20 10:48, David wrote:
In the last two weeks I've had two occurrences where a
single CentOS 7 production server
Am 27.08.20 um 19:35 schrieb Christopher Schultz:
> David,
>
> On 8/27/20 10:48, David wrote:
> > In the last two weeks I've had two occurrences where a single
> > CentOS 7 production server hosting a public webpage has become
> > unresponsive. The first time, all 300 available
> >
On 27/08/2020 19:43, Roger Marquis wrote:
> Mark Thomas wrote:
>> Those are all application issues. The application should shut itself
>> down cleanly. Tomcat is complaining because it hasn't.
>
> I don't know Mark, most Java/Tomcat engineers expect an application to
> shutdown when it's
On 27/08/2020 18:57, David wrote:
> On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
> wrote:
Is there a graceful way to script the termination of threads in
case Tomcat isn't able to for whatever reason?
>
> Not really.
What you can do is take a thread dump when this happens so
Are you sure, that the Tomcat you reach under the ip and port is the
same, than that you reach by dns?
Have you checked, whether the Java version running Tomcat is new enough
to read the class lib.Text?
Are there any other errors in catalina.out or localhost.DATE.log in the
Tomcat instance, that
Am 27.08.20 um 11:47 schrieb Gokhan Akgul:
> Hi ,
>
> I have been facing the deadlock issue for the last 2 months about
> JDBCPoolCleaner Thread .
>
> Following config set in context.xml
>
> auth="Container"
> type="javax.sql.DataSource"
>
Mark Thomas wrote:
Those are all application issues. The application should shut itself
down cleanly. Tomcat is complaining because it hasn't.
I don't know Mark, most Java/Tomcat engineers expect an application to
shutdown when it's os/container/shell/parent shuts-down. Can you help
us
Chris,
Thank you very much for the help. Follows the $unzip -v aprenonline.war
output.
I've put away a whole folder of sql sources that the war contains just to
make this output shorter. The reference to Text.class is in the sixth
position of WEB-INF files.
This is it:
Archive:
I had a similar issue with JDBC and it got fixed by adding this
parameter 'numTestsPerEvictionRun'=> '3',
'auth' => 'Container',
'driverClassName' => 'oracle.jdbc.OracleDriver',
'maxActive' =>
On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> David,
>
> On 8/27/20 10:48, David wrote:
> > In the last two weeks I've had two occurrences where a single
> > CentOS 7 production server hosting a public webpage has become
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gokhan,
On 8/27/20 05:47, Gokhan Akgul wrote:
> Hi ,
>
> I have been facing the deadlock issue for the last 2 months about
> JDBCPoolCleaner Thread .
>
> Following config set in context.xml
>
> type="javax.sql.DataSource"
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Carles,
On 8/27/20 12:19, Carles Franquesa wrote:
> Hi Everybody!, Just got in the list :)
>
> I am developing a webapp with Netbeans 8.0.2, and deploying it as a
> WAR file with Apache 8.5.57 Tomcat Manager onto my VPS where a
> mydomain.com is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 8/27/20 10:48, David wrote:
> In the last two weeks I've had two occurrences where a single
> CentOS 7 production server hosting a public webpage has become
> unresponsive. The first time, all 300 available
> "https-jsse-nio-8443" threads
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Merka,
On 8/27/20 06:32, Phoenix, Merka wrote:
> I think what the Qualys scan is trying to flag is that the server
> (Tomcat) is listening for both secured and unsecured traffic on
> the _same_ TCP port when the server should be listening for just
Hi Everybody!, Just got in the list :)
I am developing a webapp with Netbeans 8.0.2, and deploying it as a WAR
file with Apache 8.5.57 Tomcat Manager onto my VPS where a mydomain.com is
publically mapped on the DNS.
It works fine in localhost, and even at the VPS when the IP and path is set
in
In the last two weeks I've had two occurrences where a single CentOS 7
production server hosting a public webpage has become unresponsive. The
first time, all 300 available "https-jsse-nio-8443" threads were consumed,
with the max age being around 45minutes, and all in a "S" status. This time
On 27/08/2020 11:32, Phoenix, Merka wrote:
> The error message returned by the Tomcat service, while certainly helpful to
> the remote client, is returning more information than it should (from a
> security-viewpoint).
What, exactly, are the security concerns here? Your comment suggests
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, 27 August, 2020 00:42
To: users@tomcat.apache.org
Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys
... (from earlier in this thread)
> On Wed, Aug 26, 2020 at 7:53 AM Pratik
Hi ,
I have been facing the deadlock issue for the last 2 months about
JDBCPoolCleaner Thread .
Following config set in context.xml
Thread dump
Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16 state=BLOCKED
- waiting to lock <0x57dcb0b7> (a com.mysql.jdbc.JDBC4PreparedStatement)
Mark,
Sorry for Top-posting.
I’m still wondering what is causing this Qualys finding.
I remember times when you got only garbage when you connected with http to
https. Probably Qualys was fine with that.
Now you get a nice 400 message that helps the user understand his mistake and
Qualys
On 27/08/2020 06:31, Terence M. Bandoian wrote:
> On 8/26/2020 11:27 PM, Pratik Shrestha wrote:
>> For me, there are two options for the fix which I am not able to make
>> them
>> work.
>>
>> 1. Either show 'ERR_EMPTY_RESP' like old Tomcat version 7 used to
>> show. As
>> far as I know, with
28 matches
Mail list logo
