Re: OCSP with openSSL

2019-05-23 Thread Усманов Азат Анварович


Chris,
Yes the version is the same in
/usr/local/openssl/bin/openssl as well.
It is the same version Tomcat uses,I get this info in the logs

23-May-2019 12:55:42.145 INFO [main] org.apache.catalina.core.AprLife
cycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL
1.1.1a  20 Nov 2018]

От: Christopher Schultz 
Отправлено: 23 мая 2019 г. 18:04:29
Кому: Усманов Азат Анварович
Тема: Re: OCSP with openSSL

Азат,

On 5/22/19 14:02, Усманов Азат Анварович wrote:
> [root] ~# openssl version
> OpenSSL 1.1.1a  20 Nov 2018

Great. Is this also the same version in /usr/local/openssl/bin/openssl?

> [root] ~# openssl  ocsp -help
> Usage: ocsp [options]

Excellent.

When you launch Tomcat, are you getting a message about the version of
OpenSSL in use, and does it agree with above?

AFAIK, OCSP is enabled by default in libtcnative. There were some posts
a few months/years ago about someone trying to get it to work, and
having to edit the JVM's security.properties file and all kinds of weird
stuff. I must admit it didn't make any sense to me at the time. I'm
sorry, but I don't personally have any experience with dealing with
OCSP, but hopefully this additio0nal information will give someone else
some good info.

-chris

> 
> От: Christopher Schultz 
> Отправлено: 22 мая 2019 г. 19:45
> Кому: users@tomcat.apache.org
> Тема: Re: OCSP with openSSL
>
> Усманов,
>
> On 5/22/19 07:28, Усманов Азат Анварович wrote:
>> Mark,  I installed it  just   by  downloading  tcnative src  tar.gz
>> file from tomcat  website and issued  ./configure
>> --with-apr=/usr/local/apr --with-java-home=/usr/java/jdk1.7.0_79
>> -with-ssl=/usr/local/openssl && make && make install && make clean
>> I'm not sure  how to specify any ocsp related configure options
>> when building tomcat nativefrom source
>
> What is your OpenSSL version and capabilities?
>
> $ openssl version
>
> $ openssl -help
>
> $ openssl ocsp -help
>
> -chris
>
>>  От: Mark Thomas
>>  Отправлено: 22 мая 2019 г. 13:41 Кому:
>> users@tomcat.apache.org Тема: Re: OCSP with openSSL
>
>> On 22/05/2019 11:28, Усманов Азат Анварович wrote:
>>> Hi everyone! I have a web app running on tomcat and java 7 using
>>> apr for TLS related issues. I m still unable to have OCSP
>>> verification working with tomcat.
>
>> 
>
>>> I have tried running tcpdump on the server but don't' see any
>>> Comodo related IP addresses in the output when I access the
>>> server in question in the browser. At this point I don't know
>>> what else to do, If it was java I would just put some
>>> System.out.println statements in OCSP SSL related source code and
>>> recompile the tomcat source, but since in my case tomcat uses
>>> OpenSSL and tomcat native I'm not sure how/where to do that. the
>>> only places I found in the TC-native source that mentions OCSP
>>> is sslutils.c  source file. I'm not sure when/ if it is actually
>>> gets called in my case. Maybe be someone with more c experience
>>> c++ would help me with that.  I really want to get to the bottom
>>> of this. Any help is appreciated my tomcat version  is 8.5.39 APR
>>> based Apache Tomcat Native library [1.2.21] using APR version
>>> [1.6.5]. Openssl version is [OpenSSL 1.1.1a  20 Nov 2018 OS:
>>> Linux RHEL 6.6
>
>> How did you build the Tomcat Native library? Was OCSP enabled?
>
>> Mark
>
>> -
>
>
> 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: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Hi Rémy,

Many thanks for your tip!

I added this parameter to the Connector and now it works! So it seems that
the new async IO was causing the issue.
First feeling is that response times are a little bit lower now but still
better than HTTP/1.1

Should we see this as an issue in our code which requires (for some reason)
that scripts are loaded in some sequence or is this something that needs to
be fixed?

Tnx again for helping us to resolve this, much appreciated!

Regards,
/Tom



On Thu, May 23, 2019 at 10:04 PM Rémy Maucherat  wrote:

> On Thu, May 23, 2019 at 8:44 PM Tom Coudyzer  wrote:
>
> > Hi,
> >
> > I tested with the 9.0.21-dev version and the issue is still there.
> > I attached two screenshots on what is happening in Chrome (same behavior
> > is present in Firefox). In Internet Explorer 11 there are no errors.
> >
> > While I wait on some feedback will try to find out how I can enable the
> > logging (with more info). As I told earlier Tomcat is embedded in an
> > application and it looks something has changed to the standard logging
> > mechanism. Since I was only asked recently to have a look at this
> product I
> > need to find this out.Think we'll need this so that we can see what's
> going
> > on.
> >
> > When I need to try something or you have some ideas, just let me know.
> > Will try them out.
> >
>
> Ok, so the new async IO might be the cause of your problem, you should set
> useAsyncIO="false" on the connector.
>
> I don't know what your page is doing, but I pulled the HTTP/2 test page we
> did demo with at conferences and if I insist I can see problems.
> This is caused by the check line 1530 in Http2UpgradeHandler, the state
> being CLOSED_RX (so no window updating normally). If I comment it out, I
> see no error or problems anymore in the logs, and things work reliably. So
> maybe it's a processing ordering problem caused by async. I added some sync
> in the parser and it works too, not sure why right now.
>
> Rémy
>
>
> >
> > Thanks already!
> >
> > /Tom
> >
> >
> > On Thu, May 23, 2019 at 3:42 PM Mark Thomas  wrote:
> >
> >> On 23/05/2019 11:52, Tom Coudyzer wrote:
> >> > Hi Mark,
> >> >
> >> > Thanks for the info.
> >> >
> >> > If you say where we can download the test build we are happy to do
> that
> >> and
> >> > see if it makes any difference.
> >>
> >> http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
> >>
> >> > No problem if any (serious) issues can occur, we'll have the fire
> >> > extinguishers ready :-)
> >>
> >> Great. I just wanted you to be aware that this only a test build and is
> >> in no way an official ASF release.
> >>
> >> Let us know how you get on.
> >>
> >> Thanks,
> >>
> >> Mark
> >>
> >>
> >> >
> >> > Once again many thanks for your help, much appreciated!
> >> >
> >> > Regards,
> >> > Tom
> >> >
> >> > On Thu, May 23, 2019 at 11:09 AM Mark Thomas 
> wrote:
> >> >
> >> >> On 23/05/2019 09:04, Tom Coudyzer wrote:
> >> >>> Hi,
> >> >>>
> >> >>> We analyzed the problem further and we have set up another version
> >> which
> >> >> is
> >> >>> using Tomcat 9.0.19. We don't have the issue anymore. So it looks
> like
> >> >> it's
> >> >>> caused by something that has changed between the two versions. Based
> >> on
> >> >> the
> >> >>> info I have it looks like Chrome is stalling and getting too many
> >> >> responses
> >> >>> at the same time. In the meantime we activated already the access
> log
> >> and
> >> >>> all files in that file are sent with status 200. So it looks like a
> >> >> client
> >> >>> / browser side issue.
> >> >>>
> >> >>> Does this information give more information on what could be causing
> >> the
> >> >>> problem or which parameter we should set up / change or do you still
> >> need
> >> >>> more information?
> >> >>
> >> >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue
> looks
> >> >> more likely than a browser issue.
> >> >>
> >> >> If I point you towards a test build (no guarantees, use at your own
> >> >> risk, if your server catches fire don't blame me etc.) for 9.0.21
> could
> >> >> you test that as there are some HTTP/2 changes in 9.0.20 that made a
> >> >> long standing bug more likely that have been fixed in 9.0.21-dev.
> >> >>
> >> >> If you still see the issue then we can look at specific debug logging
> >> >> and/or isolated test cases.
> >> >>
> >> >> Mark
> >> >>
> >> >>
> >> >>>
> >> >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas 
> wrote:
> >> >>>
> >>  On 22/05/2019 15:47, Tom Coudyzer wrote:
> >> > Hi,
> >> >
> >> > We wanted to upgrade our application to start using HTTP/2. We
> added
> >> >> the
> >> > necessary and we see that the browser is using HTTP/2 in the
> >> browsers'
> >> > development tools.
> >> >
> >> > However since we activated it we get random CONNECTION_CLOSED 200
> >> >> Errors
> >>  in
> >> > Chrome. It's not always on the same files and sometimes there are
> >> more,
> >> > sometimes there are less, sometimes it works. When 

Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Hi Marc,

Was indeed a pity that it was not resolved but I applied the asyncIO=false
attribute to the Connector as Rémy suggested and it works now. So that's
good news. Just asked him if this is an issue on our (code) side or if this
is something that needs to be looked into/fixed.

Ok, for the attachments, did not know if they would be accepted or not.
For your reference you can find the screenshots here to see what's going on
in the browser with the ERR_CONNECTION_CLOSED

https://pasteboard.co/Ig4O8SZ.png
https://pasteboard.co/Ig4OlUE.png

I activated this logging but nothing seems to happen, so will need to find
out what the original developers of this application did to "disable" this.

As always, many thanks for your help!

Regards,
/Tom

On Thu, May 23, 2019 at 10:00 PM Mark Thomas  wrote:

> On 23/05/2019 19:37, Tom Coudyzer wrote:
> > Hi,
> >
> > I tested with the 9.0.21-dev version and the issue is still there.
>
> Drat.
>
> > I attached two screenshots on what is happening in Chrome (same behavior
> > is present in Firefox). In Internet Explorer 11 there are no errors.
>
> Attachments are blocked on this list. Can you either send them to me
> directly or post them somewhere and provide a link please?
>
> > While I wait on some feedback will try to find out how I can enable the
> > logging (with more info).
>
> In logging.properties
> org.apache.coyote.http2.level = FINE
>
> It should already be there but commented out.
>
> You will get a LOT of data.
>
> > As I told earlier Tomcat is embedded in an
> > application and it looks something has changed to the standard logging
> > mechanism.
>
> Ah. That might make it a bit trickier. Hopefully the info above will help.
>
> Mark
>
>
> > Since I was only asked recently to have a look at this
> > product I need to find this out.Think we'll need this so that we can see
> > what's going on.
> >
> > When I need to try something or you have some ideas, just let me know.
> > Will try them out.
> >
> > Thanks already!
> >
> > /Tom
> >
> >
> > On Thu, May 23, 2019 at 3:42 PM Mark Thomas  > > wrote:
> >
> > On 23/05/2019 11:52, Tom Coudyzer wrote:
> > > Hi Mark,
> > >
> > > Thanks for the info.
> > >
> > > If you say where we can download the test build we are happy to do
> > that and
> > > see if it makes any difference.
> >
> > http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
> >
> > > No problem if any (serious) issues can occur, we'll have the fire
> > > extinguishers ready :-)
> >
> > Great. I just wanted you to be aware that this only a test build and
> is
> > in no way an official ASF release.
> >
> > Let us know how you get on.
> >
> > Thanks,
> >
> > Mark
> >
> >
> > >
> > > Once again many thanks for your help, much appreciated!
> > >
> > > Regards,
> > > Tom
> > >
> > > On Thu, May 23, 2019 at 11:09 AM Mark Thomas  > > wrote:
> > >
> > >> On 23/05/2019 09:04, Tom Coudyzer wrote:
> > >>> Hi,
> > >>>
> > >>> We analyzed the problem further and we have set up another
> > version which
> > >> is
> > >>> using Tomcat 9.0.19. We don't have the issue anymore. So it
> > looks like
> > >> it's
> > >>> caused by something that has changed between the two versions.
> > Based on
> > >> the
> > >>> info I have it looks like Chrome is stalling and getting too many
> > >> responses
> > >>> at the same time. In the meantime we activated already the
> > access log and
> > >>> all files in that file are sent with status 200. So it looks
> like a
> > >> client
> > >>> / browser side issue.
> > >>>
> > >>> Does this information give more information on what could be
> > causing the
> > >>> problem or which parameter we should set up / change or do you
> > still need
> > >>> more information?
> > >>
> > >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue
> > looks
> > >> more likely than a browser issue.
> > >>
> > >> If I point you towards a test build (no guarantees, use at your
> own
> > >> risk, if your server catches fire don't blame me etc.) for 9.0.21
> > could
> > >> you test that as there are some HTTP/2 changes in 9.0.20 that
> made a
> > >> long standing bug more likely that have been fixed in 9.0.21-dev.
> > >>
> > >> If you still see the issue then we can look at specific debug
> logging
> > >> and/or isolated test cases.
> > >>
> > >> Mark
> > >>
> > >>
> > >>>
> > >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  > > wrote:
> > >>>
> >  On 22/05/2019 15:47, Tom Coudyzer wrote:
> > > Hi,
> > >
> > > We wanted to upgrade our application to start using HTTP/2. We
> > added
> > >> the
> > > necessary and we see that the browser is using 

Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Rémy Maucherat
On Thu, May 23, 2019 at 8:44 PM Tom Coudyzer  wrote:

> Hi,
>
> I tested with the 9.0.21-dev version and the issue is still there.
> I attached two screenshots on what is happening in Chrome (same behavior
> is present in Firefox). In Internet Explorer 11 there are no errors.
>
> While I wait on some feedback will try to find out how I can enable the
> logging (with more info). As I told earlier Tomcat is embedded in an
> application and it looks something has changed to the standard logging
> mechanism. Since I was only asked recently to have a look at this product I
> need to find this out.Think we'll need this so that we can see what's going
> on.
>
> When I need to try something or you have some ideas, just let me know.
> Will try them out.
>

Ok, so the new async IO might be the cause of your problem, you should set
useAsyncIO="false" on the connector.

I don't know what your page is doing, but I pulled the HTTP/2 test page we
did demo with at conferences and if I insist I can see problems.
This is caused by the check line 1530 in Http2UpgradeHandler, the state
being CLOSED_RX (so no window updating normally). If I comment it out, I
see no error or problems anymore in the logs, and things work reliably. So
maybe it's a processing ordering problem caused by async. I added some sync
in the parser and it works too, not sure why right now.

Rémy


>
> Thanks already!
>
> /Tom
>
>
> On Thu, May 23, 2019 at 3:42 PM Mark Thomas  wrote:
>
>> On 23/05/2019 11:52, Tom Coudyzer wrote:
>> > Hi Mark,
>> >
>> > Thanks for the info.
>> >
>> > If you say where we can download the test build we are happy to do that
>> and
>> > see if it makes any difference.
>>
>> http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
>>
>> > No problem if any (serious) issues can occur, we'll have the fire
>> > extinguishers ready :-)
>>
>> Great. I just wanted you to be aware that this only a test build and is
>> in no way an official ASF release.
>>
>> Let us know how you get on.
>>
>> Thanks,
>>
>> Mark
>>
>>
>> >
>> > Once again many thanks for your help, much appreciated!
>> >
>> > Regards,
>> > Tom
>> >
>> > On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:
>> >
>> >> On 23/05/2019 09:04, Tom Coudyzer wrote:
>> >>> Hi,
>> >>>
>> >>> We analyzed the problem further and we have set up another version
>> which
>> >> is
>> >>> using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
>> >> it's
>> >>> caused by something that has changed between the two versions. Based
>> on
>> >> the
>> >>> info I have it looks like Chrome is stalling and getting too many
>> >> responses
>> >>> at the same time. In the meantime we activated already the access log
>> and
>> >>> all files in that file are sent with status 200. So it looks like a
>> >> client
>> >>> / browser side issue.
>> >>>
>> >>> Does this information give more information on what could be causing
>> the
>> >>> problem or which parameter we should set up / change or do you still
>> need
>> >>> more information?
>> >>
>> >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
>> >> more likely than a browser issue.
>> >>
>> >> If I point you towards a test build (no guarantees, use at your own
>> >> risk, if your server catches fire don't blame me etc.) for 9.0.21 could
>> >> you test that as there are some HTTP/2 changes in 9.0.20 that made a
>> >> long standing bug more likely that have been fixed in 9.0.21-dev.
>> >>
>> >> If you still see the issue then we can look at specific debug logging
>> >> and/or isolated test cases.
>> >>
>> >> Mark
>> >>
>> >>
>> >>>
>> >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
>> >>>
>>  On 22/05/2019 15:47, Tom Coudyzer wrote:
>> > Hi,
>> >
>> > We wanted to upgrade our application to start using HTTP/2. We added
>> >> the
>> > necessary and we see that the browser is using HTTP/2 in the
>> browsers'
>> > development tools.
>> >
>> > However since we activated it we get random CONNECTION_CLOSED 200
>> >> Errors
>>  in
>> > Chrome. It's not always on the same files and sometimes there are
>> more,
>> > sometimes there are less, sometimes it works. When we disable HTTP/2
>> > (remove the upgradeprotocol tag) everything works fine.
>> >
>> > We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2
>> server.
>> >
>> > Did we configure something incorrectly, is this an HTTP/2 issue or
>> >> should
>> > we look at network issues on our end?
>> >
>> > If you need more information or we need to run something to be able
>> to
>> > troubleshoot it better please let me know.
>> >
>> > Help is much appreciated !
>> 
>>  You can try enabling debug logging if the issue is fairly easy to
>>  reproduce. That might shed some light on what Tomcat is doing and
>> why.
>> 
>>  There are also some HTTP/2 fixes due in the next set of releases that
>>  might help.
>> 
>>  Mark
>> 
>>  

Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Mark Thomas
On 23/05/2019 19:37, Tom Coudyzer wrote:
> Hi, 
> 
> I tested with the 9.0.21-dev version and the issue is still there.

Drat.
 
> I attached two screenshots on what is happening in Chrome (same behavior
> is present in Firefox). In Internet Explorer 11 there are no errors.

Attachments are blocked on this list. Can you either send them to me
directly or post them somewhere and provide a link please?

> While I wait on some feedback will try to find out how I can enable the
> logging (with more info).

In logging.properties
org.apache.coyote.http2.level = FINE

It should already be there but commented out.

You will get a LOT of data.

> As I told earlier Tomcat is embedded in an
> application and it looks something has changed to the standard logging
> mechanism.

Ah. That might make it a bit trickier. Hopefully the info above will help.

Mark


> Since I was only asked recently to have a look at this
> product I need to find this out.Think we'll need this so that we can see
> what's going on.
> 
> When I need to try something or you have some ideas, just let me know.
> Will try them out.
> 
> Thanks already!
> 
> /Tom
> 
> 
> On Thu, May 23, 2019 at 3:42 PM Mark Thomas  > wrote:
> 
> On 23/05/2019 11:52, Tom Coudyzer wrote:
> > Hi Mark,
> >
> > Thanks for the info.
> >
> > If you say where we can download the test build we are happy to do
> that and
> > see if it makes any difference.
> 
> http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
> 
> > No problem if any (serious) issues can occur, we'll have the fire
> > extinguishers ready :-)
> 
> Great. I just wanted you to be aware that this only a test build and is
> in no way an official ASF release.
> 
> Let us know how you get on.
> 
> Thanks,
> 
> Mark
> 
> 
> >
> > Once again many thanks for your help, much appreciated!
> >
> > Regards,
> > Tom
> >
> > On Thu, May 23, 2019 at 11:09 AM Mark Thomas  > wrote:
> >
> >> On 23/05/2019 09:04, Tom Coudyzer wrote:
> >>> Hi,
> >>>
> >>> We analyzed the problem further and we have set up another
> version which
> >> is
> >>> using Tomcat 9.0.19. We don't have the issue anymore. So it
> looks like
> >> it's
> >>> caused by something that has changed between the two versions.
> Based on
> >> the
> >>> info I have it looks like Chrome is stalling and getting too many
> >> responses
> >>> at the same time. In the meantime we activated already the
> access log and
> >>> all files in that file are sent with status 200. So it looks like a
> >> client
> >>> / browser side issue.
> >>>
> >>> Does this information give more information on what could be
> causing the
> >>> problem or which parameter we should set up / change or do you
> still need
> >>> more information?
> >>
> >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue
> looks
> >> more likely than a browser issue.
> >>
> >> If I point you towards a test build (no guarantees, use at your own
> >> risk, if your server catches fire don't blame me etc.) for 9.0.21
> could
> >> you test that as there are some HTTP/2 changes in 9.0.20 that made a
> >> long standing bug more likely that have been fixed in 9.0.21-dev.
> >>
> >> If you still see the issue then we can look at specific debug logging
> >> and/or isolated test cases.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  > wrote:
> >>>
>  On 22/05/2019 15:47, Tom Coudyzer wrote:
> > Hi,
> >
> > We wanted to upgrade our application to start using HTTP/2. We
> added
> >> the
> > necessary and we see that the browser is using HTTP/2 in the
> browsers'
> > development tools.
> >
> > However since we activated it we get random CONNECTION_CLOSED 200
> >> Errors
>  in
> > Chrome. It's not always on the same files and sometimes there
> are more,
> > sometimes there are less, sometimes it works. When we disable
> HTTP/2
> > (remove the upgradeprotocol tag) everything works fine.
> >
> > We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2
> server.
> >
> > Did we configure something incorrectly, is this an HTTP/2 issue or
> >> should
> > we look at network issues on our end?
> >
> > If you need more information or we need to run something to be
> able to
> > troubleshoot it better please let me know.
> >
> > Help is much appreciated !
> 
>  You can try enabling debug logging if the issue is fairly easy to
>  reproduce. That might shed some light on what Tomcat is doing
>

Re: 8.5.42 ETA?

2019-05-23 Thread Mark Thomas
On 23/05/2019 20:35, Scott Evans wrote:
> Hi, any ETA on when 8.5.42 will be released?

8.5.x is on a roughly monthly release cycle.

The typical pattern is that I (as the current release manager) start
looking at the open bugs (not enhancements) against all Tomcat versions
a few days before the end of the month. Once all the open bugs are fixed
I tag and release 9.0.x and 8.5.x. That takes about an hour. There is
then a 72 hour voting period. Assuming the votes passes, the files are
made public, the mirrors are given 24 hours to sync and then we announce.

Things never run quite that smoothly. The releases normally land some
time in the second week of the month.

Mark

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



8.5.42 ETA?

2019-05-23 Thread Scott Evans
Hi, any ETA on when 8.5.42 will be released?



Thanks!

Scott Evans


Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Hi,

I tested with the 9.0.21-dev version and the issue is still there.
I attached two screenshots on what is happening in Chrome (same behavior is
present in Firefox). In Internet Explorer 11 there are no errors.

While I wait on some feedback will try to find out how I can enable the
logging (with more info). As I told earlier Tomcat is embedded in an
application and it looks something has changed to the standard logging
mechanism. Since I was only asked recently to have a look at this product I
need to find this out.Think we'll need this so that we can see what's going
on.

When I need to try something or you have some ideas, just let me know. Will
try them out.

Thanks already!

/Tom


On Thu, May 23, 2019 at 3:42 PM Mark Thomas  wrote:

> On 23/05/2019 11:52, Tom Coudyzer wrote:
> > Hi Mark,
> >
> > Thanks for the info.
> >
> > If you say where we can download the test build we are happy to do that
> and
> > see if it makes any difference.
>
> http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
>
> > No problem if any (serious) issues can occur, we'll have the fire
> > extinguishers ready :-)
>
> Great. I just wanted you to be aware that this only a test build and is
> in no way an official ASF release.
>
> Let us know how you get on.
>
> Thanks,
>
> Mark
>
>
> >
> > Once again many thanks for your help, much appreciated!
> >
> > Regards,
> > Tom
> >
> > On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:
> >
> >> On 23/05/2019 09:04, Tom Coudyzer wrote:
> >>> Hi,
> >>>
> >>> We analyzed the problem further and we have set up another version
> which
> >> is
> >>> using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
> >> it's
> >>> caused by something that has changed between the two versions. Based on
> >> the
> >>> info I have it looks like Chrome is stalling and getting too many
> >> responses
> >>> at the same time. In the meantime we activated already the access log
> and
> >>> all files in that file are sent with status 200. So it looks like a
> >> client
> >>> / browser side issue.
> >>>
> >>> Does this information give more information on what could be causing
> the
> >>> problem or which parameter we should set up / change or do you still
> need
> >>> more information?
> >>
> >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
> >> more likely than a browser issue.
> >>
> >> If I point you towards a test build (no guarantees, use at your own
> >> risk, if your server catches fire don't blame me etc.) for 9.0.21 could
> >> you test that as there are some HTTP/2 changes in 9.0.20 that made a
> >> long standing bug more likely that have been fixed in 9.0.21-dev.
> >>
> >> If you still see the issue then we can look at specific debug logging
> >> and/or isolated test cases.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
> >>>
>  On 22/05/2019 15:47, Tom Coudyzer wrote:
> > Hi,
> >
> > We wanted to upgrade our application to start using HTTP/2. We added
> >> the
> > necessary and we see that the browser is using HTTP/2 in the
> browsers'
> > development tools.
> >
> > However since we activated it we get random CONNECTION_CLOSED 200
> >> Errors
>  in
> > Chrome. It's not always on the same files and sometimes there are
> more,
> > sometimes there are less, sometimes it works. When we disable HTTP/2
> > (remove the upgradeprotocol tag) everything works fine.
> >
> > We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2
> server.
> >
> > Did we configure something incorrectly, is this an HTTP/2 issue or
> >> should
> > we look at network issues on our end?
> >
> > If you need more information or we need to run something to be able
> to
> > troubleshoot it better please let me know.
> >
> > Help is much appreciated !
> 
>  You can try enabling debug logging if the issue is fairly easy to
>  reproduce. That might shed some light on what Tomcat is doing and why.
> 
>  There are also some HTTP/2 fixes due in the next set of releases that
>  might help.
> 
>  Mark
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Thanks Mark.

We will test and report back.

/Tom

On Thu, May 23, 2019 at 3:42 PM Mark Thomas  wrote:

> On 23/05/2019 11:52, Tom Coudyzer wrote:
> > Hi Mark,
> >
> > Thanks for the info.
> >
> > If you say where we can download the test build we are happy to do that
> and
> > see if it makes any difference.
>
> http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/
>
> > No problem if any (serious) issues can occur, we'll have the fire
> > extinguishers ready :-)
>
> Great. I just wanted you to be aware that this only a test build and is
> in no way an official ASF release.
>
> Let us know how you get on.
>
> Thanks,
>
> Mark
>
>
> >
> > Once again many thanks for your help, much appreciated!
> >
> > Regards,
> > Tom
> >
> > On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:
> >
> >> On 23/05/2019 09:04, Tom Coudyzer wrote:
> >>> Hi,
> >>>
> >>> We analyzed the problem further and we have set up another version
> which
> >> is
> >>> using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
> >> it's
> >>> caused by something that has changed between the two versions. Based on
> >> the
> >>> info I have it looks like Chrome is stalling and getting too many
> >> responses
> >>> at the same time. In the meantime we activated already the access log
> and
> >>> all files in that file are sent with status 200. So it looks like a
> >> client
> >>> / browser side issue.
> >>>
> >>> Does this information give more information on what could be causing
> the
> >>> problem or which parameter we should set up / change or do you still
> need
> >>> more information?
> >>
> >> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
> >> more likely than a browser issue.
> >>
> >> If I point you towards a test build (no guarantees, use at your own
> >> risk, if your server catches fire don't blame me etc.) for 9.0.21 could
> >> you test that as there are some HTTP/2 changes in 9.0.20 that made a
> >> long standing bug more likely that have been fixed in 9.0.21-dev.
> >>
> >> If you still see the issue then we can look at specific debug logging
> >> and/or isolated test cases.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
> >>>
>  On 22/05/2019 15:47, Tom Coudyzer wrote:
> > Hi,
> >
> > We wanted to upgrade our application to start using HTTP/2. We added
> >> the
> > necessary and we see that the browser is using HTTP/2 in the
> browsers'
> > development tools.
> >
> > However since we activated it we get random CONNECTION_CLOSED 200
> >> Errors
>  in
> > Chrome. It's not always on the same files and sometimes there are
> more,
> > sometimes there are less, sometimes it works. When we disable HTTP/2
> > (remove the upgradeprotocol tag) everything works fine.
> >
> > We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2
> server.
> >
> > Did we configure something incorrectly, is this an HTTP/2 issue or
> >> should
> > we look at network issues on our end?
> >
> > If you need more information or we need to run something to be able
> to
> > troubleshoot it better please let me know.
> >
> > Help is much appreciated !
> 
>  You can try enabling debug logging if the issue is fairly easy to
>  reproduce. That might shed some light on what Tomcat is doing and why.
> 
>  There are also some HTTP/2 fixes due in the next set of releases that
>  might help.
> 
>  Mark
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Running sudo from a servlet

2019-05-23 Thread Claude Brisson
You are right about your security concerns. I feel obliged to state that 
my use-case is perfectly valid and secure, the tomcat instance runs in a 
VPN and the sudoers file is properly configured to only allow access to 
a single user and a single command.


Anyhow it's the kind of area where you better know what you're doing.

  Claude


On 23/05/2019 11:55, Olaf Kock wrote:



I'd seriously consider whether or not you want to actually do this.

It might be better to write a tiny daemon which has elevated
privileges to perform whatever operation you want and have your web
application ping it to do some work, rather than making the whole
Tomcat process able to elevate its privileges.


Seconding this. Running a web-facing daemon with the option of executing
system commands as root is a recipe for disaster. Don't even think of
going there.

There might be rare occasions where there's a good reason for this
architecture, but the keyword here is "rare". It'll need a *very* good
reason. And "how do I enable sudo?" isn't one.

You have been warned, and so has everyone else finding this thread in
future with the intend of making the same architectural decision.

On stackoverflow, this is called the x-y problem
(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
I'd recommend reading a few of those answers and reconsider the
question, to come up with the X instead of the Y.


Olaf




-
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



Tomcat (TomEE)/9.0.12 (8.0.0-M1) JSF 2.3 - Empty Strings from form inputs expected as NULL

2019-05-23 Thread Ted Spradley
What is the current way of coercing empty string input fields to NULL With 
9.0.12? This issue seems to come up with each new major version of EL/JSF.

 

All of the previous work arounds are no longer producing null values. Surely 
I’m missing something obvious that has been published.

 

Web.xml

  


javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL

true

   

    

     org.apache.myfaces.EXPRESSION_FACTORY

     com.sun.el.ExpressionFactoryImpl   

   

 

Dropping the javax.el-3.0.1-b11.jar in WEB-INF/lib seems to have no effect.

 

Faces-config.xml

   

   com.example.EmptyToNullStringELResolver

    

 

Custom el resolver causes a null pointer exception

 

java.lang.NullPointerException

    at 
org.apache.myfaces.shared.resource.ValueExpressionFilterInputStream.read(ValueExpressionFilterInputStream.java:130)

    at java.io.InputStream.read(InputStream.java:179)

    at 
java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)

    at org.omnifaces.util.Utils.stream(Utils.java:397)

    at 
org.omnifaces.resourcehandler.UnmappedResourceHandler.handleResourceRequest(UnmappedResourceHandler.java:176)

    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:196)

    at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)

    at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

    at ...

 

 

 

Thank you,

Ted S.

 

 



Re: Migration from Tomcat 7 to 9 results in more open file descriptors

2019-05-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

On 5/23/19 06:59, Florian Trimmel wrote:
> After migrating from Tomact 7 to Tomcat 9.0.20 (running with same
> Java Version 1.8.0_25) we have a problem with our JSF2 web
> application on Linux RHEL 7. After some time we get Exceptions like
> this:
> 
> 
> 
> java.io.FileNotFoundException: 
> /f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too
> many open files)
> 
> at java.io.FileInputStream.open0(Native Method)
> 
> at java.io.FileInputStream.open(FileInputStream.java:195)
> 
> at java.io.FileInputStream.(FileInputStream.java:138)
> 
> at java.io.FileInputStream.(FileInputStream.java:93)
> 
> 
> 
> 
> 
> After searching around a while, I have found out that there are
> many open file descriptors to xhtml files

Do you know if your application opens these files, or are they
(likely) being opened by Tomcat in response to incoming client
requests for those files?

> [snip]
> 
> This is not the complete list - there are many more.
> 
> The number of listed files goes up and down. For me it seems that
> xhtml (or one of its used components) has an open file descriptor
> as long as a page is shown in Browser.

... and when you close the browser, the fd is closed too? Spooky.

> I already know how to increase the maximum number of open file
> descriptors, what bothers me is that if I deploy the same
> application on Tomcat 7 again, I can only see open file descriptors
> for JAR Files, Sockets, but NEVER for xhtml's.
> 
> Can someone please explain why this happens?

The obvious explanation would be a fd leak within Tomcat but I see no
data to support that. The "resources" (aka file-reading)
implementation changed between Tomcat 7 and 9 and if your application
is being a little lazy about resource-management, this could cause fds
to be left open now where they were being cleaned-up for you in the past
.

Improper caching configuration could also leave file descriptors open,
but multiple fds open to the same file is the exact opposite of
caching, so the configuration would have to indeed be particularly bad.

Are you able to attach a profiler to the JVM process? If so, try
launching Tomcat, attaching the profiler, and then making some
requests. The profiler ought to be able to show you where certain
objects were allocated and you can track-down where e.g.
FileInputStream objects are created. If they are being created in
Tomcat's code without being called from your application (e.g. from
within DefaultServlet), then something is very wrong.

But at this point, the new resources implementation is fairly mature
and I wouldn't expect it to leak like this.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzmuOUACgkQHPApP6U8
pFgqwg/9FUmsAS/mOin0NKIlU1LOPRyf72/gT+8n5vyquC+CBk8jWFBqxNFZEoGV
Fc+5rfwF1pqK8aTgDM2dzEb4bJ9s3sVGY/SLvspGyeRU81/uqZW4CnSGIL7VzrJk
xpTi4hk02rNFbq8yNjMDqCUx2t41Bi8NUVJh9TUtHRPZRQWhy3JsG32HQdPrPklj
AipBl/NkpizGZQlAGqMz87rYvFIEz1e1hA47CPfUFg7x8WCib7X9JcHHZYF5gQjS
y/h5IdRT9A6F1Lu2arW00cFPSfoYoZA+gHWzQMGHmTXSQplwzF8h9tafNLXf4u4u
Knav+K3KTPeskzuKUqxLTa2GwX6MNLnEnw3uicvuHT13JYncLTz6LCgSE31/xgj9
EcnME4zQca7X14DrHaldwwejuvqL/HYTVkYc6YOt24E3FCAbkcPg8MOYo1QjT408
u1GXl+n4HBgNsHO//FsAVYDEm14YXmvWyB+33aVc9OKbCk1X+vRbkq8Fe//Bz05T
72Mb5potJWGFhHVseSuiYp1XyhlgSWDqzQkqoYV8ffm5ecfbYd96gRqFxveK0S2I
9/9X6k8a/6lqQMidfNoqKfoA1G+5soI436j6LYlna4vqIgB+ZjCoTmnzJh4+NMy7
VcAZ+S2uRb3bnTccsttcNbCKOM9BD9C9rSosS3N48XDl3u5ooL4=
=B0WJ
-END PGP SIGNATURE-

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



Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Mark Thomas
On 23/05/2019 11:52, Tom Coudyzer wrote:
> Hi Mark,
> 
> Thanks for the info.
> 
> If you say where we can download the test build we are happy to do that and
> see if it makes any difference.

http://people.apache.org/~markt/dev/v9.0.21-dev-d6d3b31/

> No problem if any (serious) issues can occur, we'll have the fire
> extinguishers ready :-)

Great. I just wanted you to be aware that this only a test build and is
in no way an official ASF release.

Let us know how you get on.

Thanks,

Mark


> 
> Once again many thanks for your help, much appreciated!
> 
> Regards,
> Tom
> 
> On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:
> 
>> On 23/05/2019 09:04, Tom Coudyzer wrote:
>>> Hi,
>>>
>>> We analyzed the problem further and we have set up another version which
>> is
>>> using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
>> it's
>>> caused by something that has changed between the two versions. Based on
>> the
>>> info I have it looks like Chrome is stalling and getting too many
>> responses
>>> at the same time. In the meantime we activated already the access log and
>>> all files in that file are sent with status 200. So it looks like a
>> client
>>> / browser side issue.
>>>
>>> Does this information give more information on what could be causing the
>>> problem or which parameter we should set up / change or do you still need
>>> more information?
>>
>> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
>> more likely than a browser issue.
>>
>> If I point you towards a test build (no guarantees, use at your own
>> risk, if your server catches fire don't blame me etc.) for 9.0.21 could
>> you test that as there are some HTTP/2 changes in 9.0.20 that made a
>> long standing bug more likely that have been fixed in 9.0.21-dev.
>>
>> If you still see the issue then we can look at specific debug logging
>> and/or isolated test cases.
>>
>> Mark
>>
>>
>>>
>>> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
>>>
 On 22/05/2019 15:47, Tom Coudyzer wrote:
> Hi,
>
> We wanted to upgrade our application to start using HTTP/2. We added
>> the
> necessary and we see that the browser is using HTTP/2 in the browsers'
> development tools.
>
> However since we activated it we get random CONNECTION_CLOSED 200
>> Errors
 in
> Chrome. It's not always on the same files and sometimes there are more,
> sometimes there are less, sometimes it works. When we disable HTTP/2
> (remove the upgradeprotocol tag) everything works fine.
>
> We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2 server.
>
> Did we configure something incorrectly, is this an HTTP/2 issue or
>> should
> we look at network issues on our end?
>
> If you need more information or we need to run something to be able to
> troubleshoot it better please let me know.
>
> Help is much appreciated !

 You can try enabling debug logging if the issue is fairly easy to
 reproduce. That might shed some light on what Tomcat is doing and why.

 There are also some HTTP/2 fixes due in the next set of releases that
 might help.

 Mark

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


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


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



Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Rémy Maucherat
On Thu, May 23, 2019 at 12:53 PM Tom Coudyzer  wrote:

> Hi Mark,
>
> Thanks for the info.
>
> If you say where we can download the test build we are happy to do that and
> see if it makes any difference.
> No problem if any (serious) issues can occur, we'll have the fire
> extinguishers ready :-)
>
> Once again many thanks for your help, much appreciated!
>

Tomcat 9.0.20 has known HTTP/2 issues:
- The new async NIO code still had some random bugs that caused connection
errors
- The timeout issue which caused the connection to be often closed once it
hit its window size

The current fixed Tomcat looks ok to me with chrome, but if the problem is
rare it would be more difficult to reproduce.

Rémy


>
> Regards,
> Tom
>
> On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:
>
> > On 23/05/2019 09:04, Tom Coudyzer wrote:
> > > Hi,
> > >
> > > We analyzed the problem further and we have set up another version
> which
> > is
> > > using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
> > it's
> > > caused by something that has changed between the two versions. Based on
> > the
> > > info I have it looks like Chrome is stalling and getting too many
> > responses
> > > at the same time. In the meantime we activated already the access log
> and
> > > all files in that file are sent with status 200. So it looks like a
> > client
> > > / browser side issue.
> > >
> > > Does this information give more information on what could be causing
> the
> > > problem or which parameter we should set up / change or do you still
> need
> > > more information?
> >
> > Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
> > more likely than a browser issue.
> >
> > If I point you towards a test build (no guarantees, use at your own
> > risk, if your server catches fire don't blame me etc.) for 9.0.21 could
> > you test that as there are some HTTP/2 changes in 9.0.20 that made a
> > long standing bug more likely that have been fixed in 9.0.21-dev.
> >
> > If you still see the issue then we can look at specific debug logging
> > and/or isolated test cases.
> >
> > Mark
> >
> >
> > >
> > > On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
> > >
> > >> On 22/05/2019 15:47, Tom Coudyzer wrote:
> > >>> Hi,
> > >>>
> > >>> We wanted to upgrade our application to start using HTTP/2. We added
> > the
> > >>> necessary and we see that the browser is using HTTP/2 in the
> browsers'
> > >>> development tools.
> > >>>
> > >>> However since we activated it we get random CONNECTION_CLOSED 200
> > Errors
> > >> in
> > >>> Chrome. It's not always on the same files and sometimes there are
> more,
> > >>> sometimes there are less, sometimes it works. When we disable HTTP/2
> > >>> (remove the upgradeprotocol tag) everything works fine.
> > >>>
> > >>> We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2
> server.
> > >>>
> > >>> Did we configure something incorrectly, is this an HTTP/2 issue or
> > should
> > >>> we look at network issues on our end?
> > >>>
> > >>> If you need more information or we need to run something to be able
> to
> > >>> troubleshoot it better please let me know.
> > >>>
> > >>> Help is much appreciated !
> > >>
> > >> You can try enabling debug logging if the issue is fairly easy to
> > >> reproduce. That might shed some light on what Tomcat is doing and why.
> > >>
> > >> There are also some HTTP/2 fixes due in the next set of releases that
> > >> might help.
> > >>
> > >> Mark
> > >>
> > >> -
> > >> 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
> >
> >
>


Migration from Tomcat 7 to 9 results in more open file descriptors

2019-05-23 Thread Florian Trimmel
Hi,



After migrating from Tomact 7 to Tomcat 9.0.20 (running with same Java
Version 1.8.0_25) we have a problem with our JSF2 web application on Linux
RHEL 7. After some time we get Exceptions like this:



java.io.FileNotFoundException:
/f4m/tomcat/tomcat_f4mbs/webapps/ACM/WEB-INF/acm-config.xml (Too many open
files)

at java.io.FileInputStream.open0(Native Method)

at java.io.FileInputStream.open(FileInputStream.java:195)

at java.io.FileInputStream.(FileInputStream.java:138)

at java.io.FileInputStream.(FileInputStream.java:93)





After searching around a while, I have found out that there are many open
file descriptors to xhtml files, by executing this command (where 4025 is
the Tomcat process ID):



ls -l /proc/4025/fd





lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 238 ->
/usr/java/jdk1.8.0_25/jre/lib/resources.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 239 -> pipe:[3661823]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 24 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/websocket-api.jar

l-wx--. 1 f4mHttp f4mHttp 64 May 16 09:01 240 -> pipe:[3661823]

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 241 -> anon_inode:[eventpoll]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 243 -> pipe:[3661824]

l-wx--. 1 f4mHttp f4mHttp 64 May 16 09:01 244 -> pipe:[3661824]

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 245 -> anon_inode:[eventpoll]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 246 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 247 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lrwx--. 1 f4mHttp f4mHttp 64 May 16 09:01 248 -> socket:[3667364]

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 249 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/searchpage.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 25 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/jasper.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 250 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/searchpage.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 251 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalheader.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 252 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/customizing/nav/menu.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 253 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 254 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/nav/bottomPanel.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 255 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/nav/bottomPanel.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 256 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:01 257 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 258 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 259 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 26 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/ecj-4.9.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 260 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 261 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 262 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/common/barcodefunction_incl.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 263 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalfooterAll.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 264 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 266 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 267 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/nav/portalheader.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 268 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/portal/customizing/nav/menu.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 08:58 27 ->
/f4m/tomcat/tomcat_f4mbscrm/lib/catalina-ha.jar

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 274 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/form/partner/crmpartner_topnav.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 275 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 276 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/msgBox.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 277 ->
/f4m/tomcat/tomcat_f4mbscrm/webapps/ACM/resources/components/calendar.xhtml

lr-x--. 1 f4mHttp f4mHttp 64 May 16 09:02 278 

Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Hi Mark,

Thanks for the info.

If you say where we can download the test build we are happy to do that and
see if it makes any difference.
No problem if any (serious) issues can occur, we'll have the fire
extinguishers ready :-)

Once again many thanks for your help, much appreciated!

Regards,
Tom

On Thu, May 23, 2019 at 11:09 AM Mark Thomas  wrote:

> On 23/05/2019 09:04, Tom Coudyzer wrote:
> > Hi,
> >
> > We analyzed the problem further and we have set up another version which
> is
> > using Tomcat 9.0.19. We don't have the issue anymore. So it looks like
> it's
> > caused by something that has changed between the two versions. Based on
> the
> > info I have it looks like Chrome is stalling and getting too many
> responses
> > at the same time. In the meantime we activated already the access log and
> > all files in that file are sent with status 200. So it looks like a
> client
> > / browser side issue.
> >
> > Does this information give more information on what could be causing the
> > problem or which parameter we should set up / change or do you still need
> > more information?
>
> Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
> more likely than a browser issue.
>
> If I point you towards a test build (no guarantees, use at your own
> risk, if your server catches fire don't blame me etc.) for 9.0.21 could
> you test that as there are some HTTP/2 changes in 9.0.20 that made a
> long standing bug more likely that have been fixed in 9.0.21-dev.
>
> If you still see the issue then we can look at specific debug logging
> and/or isolated test cases.
>
> Mark
>
>
> >
> > On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
> >
> >> On 22/05/2019 15:47, Tom Coudyzer wrote:
> >>> Hi,
> >>>
> >>> We wanted to upgrade our application to start using HTTP/2. We added
> the
> >>> necessary and we see that the browser is using HTTP/2 in the browsers'
> >>> development tools.
> >>>
> >>> However since we activated it we get random CONNECTION_CLOSED 200
> Errors
> >> in
> >>> Chrome. It's not always on the same files and sometimes there are more,
> >>> sometimes there are less, sometimes it works. When we disable HTTP/2
> >>> (remove the upgradeprotocol tag) everything works fine.
> >>>
> >>> We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2 server.
> >>>
> >>> Did we configure something incorrectly, is this an HTTP/2 issue or
> should
> >>> we look at network issues on our end?
> >>>
> >>> If you need more information or we need to run something to be able to
> >>> troubleshoot it better please let me know.
> >>>
> >>> Help is much appreciated !
> >>
> >> You can try enabling debug logging if the issue is fairly easy to
> >> reproduce. That might shed some light on what Tomcat is doing and why.
> >>
> >> There are also some HTTP/2 fixes due in the next set of releases that
> >> might help.
> >>
> >> Mark
> >>
> >> -
> >> 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: Running sudo from a servlet

2019-05-23 Thread Olaf Kock


On 22.05.19 18:31, Christopher Schultz wrote:
> Claude,
>
> On 5/21/19 14:20, Claude Brisson wrote:
> > (responding to myself)
>
> > The culprit is the option
>
> > NoNewPrivileges=true
>
> > in the file
> > /etc/systemd/system/multi-user.target.wants/tomcat8.service
>
> > When changed to false, one must also call 'systemctl daemon-reload'
> > and after a tomcat restart, the problem is solved.
>
> I'd seriously consider whether or not you want to actually do this.
>
> It might be better to write a tiny daemon which has elevated
> privileges to perform whatever operation you want and have your web
> application ping it to do some work, rather than making the whole
> Tomcat process able to elevate its privileges.


Seconding this. Running a web-facing daemon with the option of executing
system commands as root is a recipe for disaster. Don't even think of
going there.

There might be rare occasions where there's a good reason for this
architecture, but the keyword here is "rare". It'll need a *very* good
reason. And "how do I enable sudo?" isn't one.

You have been warned, and so has everyone else finding this thread in
future with the intend of making the same architectural decision.

On stackoverflow, this is called the x-y problem
(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
I'd recommend reading a few of those answers and reconsider the
question, to come up with the X instead of the Y.


Olaf




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



Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Mark Thomas
On 23/05/2019 09:04, Tom Coudyzer wrote:
> Hi,
> 
> We analyzed the problem further and we have set up another version which is
> using Tomcat 9.0.19. We don't have the issue anymore. So it looks like it's
> caused by something that has changed between the two versions. Based on the
> info I have it looks like Chrome is stalling and getting too many responses
> at the same time. In the meantime we activated already the access log and
> all files in that file are sent with status 200. So it looks like a client
> / browser side issue.
> 
> Does this information give more information on what could be causing the
> problem or which parameter we should set up / change or do you still need
> more information?

Given the issue appears between 9.0.19 and 9.0.20 a Tomcat issue looks
more likely than a browser issue.

If I point you towards a test build (no guarantees, use at your own
risk, if your server catches fire don't blame me etc.) for 9.0.21 could
you test that as there are some HTTP/2 changes in 9.0.20 that made a
long standing bug more likely that have been fixed in 9.0.21-dev.

If you still see the issue then we can look at specific debug logging
and/or isolated test cases.

Mark


> 
> On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:
> 
>> On 22/05/2019 15:47, Tom Coudyzer wrote:
>>> Hi,
>>>
>>> We wanted to upgrade our application to start using HTTP/2. We added the
>>> necessary and we see that the browser is using HTTP/2 in the browsers'
>>> development tools.
>>>
>>> However since we activated it we get random CONNECTION_CLOSED 200 Errors
>> in
>>> Chrome. It's not always on the same files and sometimes there are more,
>>> sometimes there are less, sometimes it works. When we disable HTTP/2
>>> (remove the upgradeprotocol tag) everything works fine.
>>>
>>> We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2 server.
>>>
>>> Did we configure something incorrectly, is this an HTTP/2 issue or should
>>> we look at network issues on our end?
>>>
>>> If you need more information or we need to run something to be able to
>>> troubleshoot it better please let me know.
>>>
>>> Help is much appreciated !
>>
>> You can try enabling debug logging if the issue is fairly easy to
>> reproduce. That might shed some light on what Tomcat is doing and why.
>>
>> There are also some HTTP/2 fixes due in the next set of releases that
>> might help.
>>
>> Mark
>>
>> -
>> 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: Configuring log format for console output (catalina.out)

2019-05-23 Thread Joan
Thanks Guido,

I hope that with the rsyslog magic (see
startmsg.regex="^[[:digit:]]{2}-[[:alpha:]]{3}-[[:digit:]]{4}
[[:digit:]]{1,2}:[[:digit:]]{1,2}:[[:digit:]]{1,2}\\.[[:digit:]]{3}"  for
the reference), I will be able to group this messages, otherwise I'll jump
into your solution.

Joan

Missatge de Jäkel, Guido  del dia dc., 22 de maig 2019 a
les 8:55:

> Dear Joan,
>
> by use of the common scripts, the file  catalina.out  will contain the
> console output (stdout/tderr) of the *JVM* process and -- if not configured
> in another way -- of the applications. Therefore, you have to deal with the
> features of output formatting of current JVMs. Or -- as me -- you might
> pipe this file descriptors through a tiny script that will prepend a
> timestamp in a format of your choice. This will have the advantage that it
> also handle "console" output of Java application; despite of the fact that
> using stdout/stderr instead of a java logging mechanism is a very bad style.
>
> If you don't need to process thousands of lines per second, a simple shell
> script may do the job:
>
> while read line; do echo "`date -Ins` $line"; done
>
> To avoid "double-stamping", you may add an heuristic check of the incoming
> line; please adjust the RegExpr to your neeeds
>
> while read line; do [[ ! "$line" =~ ^\d\d\d\d ]] && echo -n
> "[`date -Ins`] "; echo $line; done
>
>
> Guido
>


Re: CONNECTION_CLOSED 200 Error with HTTP/2 Enabled

2019-05-23 Thread Tom Coudyzer
Hi,

We analyzed the problem further and we have set up another version which is
using Tomcat 9.0.19. We don't have the issue anymore. So it looks like it's
caused by something that has changed between the two versions. Based on the
info I have it looks like Chrome is stalling and getting too many responses
at the same time. In the meantime we activated already the access log and
all files in that file are sent with status 200. So it looks like a client
/ browser side issue.

Does this information give more information on what could be causing the
problem or which parameter we should set up / change or do you still need
more information?

On Wed, May 22, 2019 at 5:01 PM Mark Thomas  wrote:

> On 22/05/2019 15:47, Tom Coudyzer wrote:
> > Hi,
> >
> > We wanted to upgrade our application to start using HTTP/2. We added the
> > necessary and we see that the browser is using HTTP/2 in the browsers'
> > development tools.
> >
> > However since we activated it we get random CONNECTION_CLOSED 200 Errors
> in
> > Chrome. It's not always on the same files and sometimes there are more,
> > sometimes there are less, sometimes it works. When we disable HTTP/2
> > (remove the upgradeprotocol tag) everything works fine.
> >
> > We are running Tomcat 9.0.20 (x64) on a Windows Server 2008 R2 server.
> >
> > Did we configure something incorrectly, is this an HTTP/2 issue or should
> > we look at network issues on our end?
> >
> > If you need more information or we need to run something to be able to
> > troubleshoot it better please let me know.
> >
> > Help is much appreciated !
>
> You can try enabling debug logging if the issue is fairly easy to
> reproduce. That might shed some light on what Tomcat is doing and why.
>
> There are also some HTTP/2 fixes due in the next set of releases that
> might help.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>