Re: HTTP/2 configuration

[Arief Hasani]

 Hi Mark,
IMHO, being able to override form HTTP1.1 conf is all good as user could easily 
assume that if not specified in the upgrade than use http1.1 configs
Cheers
   
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
  

Re: remote jmx monitoring through ssh tunnel

[logo]

Chris

> Am 11.12.2019 um 21:46 schrieb Chris Cheshire  >:
> 
> Peter,
> 
> On Wed, Dec 11, 2019 at 2:38 AM Peter Kreuser  > wrote:
>> 
>> Chris‘,
>> 
>>> Am 10.12.2019 um 18:59 schrieb Chris Cheshire >> >:
>>> 
>>> On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire >> > wrote:
 
> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz
> mailto:ch...@christopherschultz.net>> 
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Chris,
> 
> On 12/9/19 17:10, Chris Cheshire wrote:
>> In CATALINA_BASE/bin/setenv.sh I have the following :
>> 
>> CATALINA_OPTS="-Dcom.sun.management.jmxremote
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false"
> 
> Okay.
> 
>> In CATALINA_BASE/conf/server.xml I have a listener configured :
>> 
>> > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>> rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>> useLocalPorts="true" />
>> 
>> 
>> Upon startup I see in logs : INFO [main]
>> org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer
>> The JMX Remote Listener has configured the registry on port
>> [10001] and the server on port [10002] for the [Platform] server
>> 
>> 
>> 
>> I didn‘t read it anywhere. Did you add the catalina-jmx.jar to the classpath?
>> 
>> Peter
>> 
> 
> What is that jar and where does it come from? I don't see it in the TC
> 9 distribution, nor can I find mention of it in the docs [1] [2]
> 

https://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener
 


It’s called catalina-jmx-remote.jar and it’s an extra DL 
https://tomcat.apache.org/download-80.cgi#8.5.49 
 see „Extras"

Peter


> Chris
> 
> [1] https://tomcat.apache.org/tomcat-9.0-doc/monitoring.html 
> 
> [2] https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

smime.p7s
Description: S/MIME cryptographic signature

Re: remote jmx monitoring through ssh tunnel

[Chris Cheshire]

On Wed, Dec 11, 2019 at 12:24 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 12/10/19 12:59, Chris Cheshire wrote:
> > On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire
> >  wrote:
> >>
> >> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz
> >>  wrote:
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>>
> >>> Chris,
> >>>
> >>> On 12/9/19 17:10, Chris Cheshire wrote:
>  In CATALINA_BASE/bin/setenv.sh I have the following :
> 
>  CATALINA_OPTS="-Dcom.sun.management.jmxremote
>  -Dcom.sun.management.jmxremote.ssl=false
>  -Dcom.sun.management.jmxremote.authenticate=false"
> >>>
> >>> Okay.
> >>>
>  In CATALINA_BASE/conf/server.xml I have a listener configured
>  :
> 
>    className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> 
> 
> rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>  useLocalPorts="true" />
> 
> 
>  Upon startup I see in logs : INFO [main]
>  org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer
> 
> 
> The JMX Remote Listener has configured the registry on port
>  [10001] and the server on port [10002] for the [Platform]
>  server
> 
> 
>  $ netstat -an | grep 10001 tcp4   0  0
>  127.0.0.1.10001 *.*LISTEN tcp6   0
>  0  ::1.10001 *.*LISTEN
> 
>  On my local machine I have a tunnel set up as follows : ssh
>  -N -L10001:localhost:10001 -L10002:localhost:10002
>  user@remotehost
> 
>  (where user is the user tomcat is running under)
> 
>  When I try to add a remote JMX connection in VisualVM on my
>  client machine to localhost:10001 I get an error dialog after
>  a brief delay with the message "Cannot connect to
>  localhost:10001 using
>  service:jmx:rmi:///jndi/rmi://localhost:10001/jmxrmi". If I
>  change it to port 10002 I get the same error. On the server
>  at this time : $ netstat -an | grep 10001 tcp4   0  0
>  127.0.0.1.10001 *.*LISTEN tcp6   0
>  0  ::1.10001 *.*LISTEN tcp4   0
>  0  127.0.0.1.62637 127.0.0.1.10001TIME_WAIT
> 
> 
>  If I try to use jconsole connecting to port 10001 I get the
>  error "Connection failed: non-JRMP server at remote
>  endpoint". Connecting to port 10002 I get the error
>  "Connection failed: no such object in table"
> >>>
> >>> You should be using the port defined by
> >>> rmiRegistryPortPlatform, so 10001 is the correct port to use.
> >>>
>  I've been through the tomcat configuration documentation a
>  couple times but I can't see what else I need to configure.
> >>>
> >>> What you have looks good to me without reproducing it myself.
> >>> Can you do :
> >>>
> >>> $ netstat -an | grep 1000[0-9]
> >>>
> >>> ?
> >>>
> >>> Just to be sure about both ports?
> >>>
> >>
> >> $ netstat -an | grep 1000[0-9] tcp6   0  0 :::10001
> >> :::*LISTEN tcp6   0  0 :::10002
> >> :::*LISTEN
> >>
> >>
> >> H. Tomcat is only listening on ipv6 ports, but my tunnel is
> >> using ipv4. After digging around [1], I added this to
> >> CATALINA_OPTS in setenv.sh
> >>
> >> -Djava.net.preferIPv4Stack=true
> >> -Djava.net.preferIPv4Addresses=true
> >>
> >> $ netstat -an | grep 1000[0-9] tcp0  0 0.0.0.0:10001
> >> 0.0.0.0:*   LISTEN tcp0  0 0.0.0.0:10002
> >> 0.0.0.0:*   LISTEN
> >>
> >> When I try to connect with jconsole I get the same error
> >> (non-JRMP server at remote endpoint), with the server showing
> >>
> >> tcp0  0 0.0.0.0:10001   0.0.0.0:*
> >> LISTEN tcp0  0 0.0.0.0:10002   0.0.0.0:*
> >> LISTEN tcp0  0 127.0.0.1:10001
> >> 127.0.0.1:43803 TIME_WAIT tcp0  0
> >> 127.0.0.1:10001 127.0.0.1:43815 TIME_WAIT
> >>
> >>
> >> I have also updated sshd_config with
> >>
> >> PermitTunnel yes
> >>
> >> and restarted that. Still no change.
> >>
> >> Chris
> >>
> >>
> >> [1]
> >> https://serverfault.com/questions/390840/how-does-one-get-tomcat-to-b
> ind-to-ipv4-address
> >
> >>
> >
> > As a followup to take the tunnel out of the equation I downloaded
> > jmxterm [1] on the server and tried to connect
> >
> >
> > $ java -jar jmxterm-1.0.0-uber.jar Welcome to JMX terminal. Type
> > "help" for available commands. $>open localhost:10001
> > #RuntimeIOException: Runtime IO exception: Failed to retrieve
> > RMIServer stub: javax.naming.CommunicationException [Root exception
> > is java.rmi.ConnectIOException: non-JRMP server at remote
> > endpoint] $>
> >
> >
> > Back to the tomcat documentation, I added this to CATALINA_OPTS
> > (based on listener config and assumed defaults)
> >
> > -Dcom.sun.management.jmxremote.registry.ssl=false
> >
> > and now I get a different error : 

Re: remote jmx monitoring through ssh tunnel

[Chris Cheshire]

Peter,

On Wed, Dec 11, 2019 at 2:38 AM Peter Kreuser  wrote:
>
> Chris‘,
>
> > Am 10.12.2019 um 18:59 schrieb Chris Cheshire :
> >
> > On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire  
> > wrote:
> >>
> >>> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz
> >>>  wrote:
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> Chris,
> >>>
> >>> On 12/9/19 17:10, Chris Cheshire wrote:
>  In CATALINA_BASE/bin/setenv.sh I have the following :
> 
>  CATALINA_OPTS="-Dcom.sun.management.jmxremote
>  -Dcom.sun.management.jmxremote.ssl=false
>  -Dcom.sun.management.jmxremote.authenticate=false"
> >>>
> >>> Okay.
> >>>
>  In CATALINA_BASE/conf/server.xml I have a listener configured :
> 
>    className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>  rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>  useLocalPorts="true" />
> 
> 
>  Upon startup I see in logs : INFO [main]
>  org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer
>  The JMX Remote Listener has configured the registry on port
>  [10001] and the server on port [10002] for the [Platform] server
> 
> 
>
> I didn‘t read it anywhere. Did you add the catalina-jmx.jar to the classpath?
>
> Peter
>

What is that jar and where does it come from? I don't see it in the TC
9 distribution, nor can I find mention of it in the docs [1] [2]

Chris

[1] https://tomcat.apache.org/tomcat-9.0-doc/monitoring.html
[2] https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html

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

Re: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/11/19 13:01, Mark Thomas wrote:
> On 11/12/2019 17:43, Christopher Schultz wrote:
> 
> 
> 
>>> I'm not sure why we need this over and above the RequestFacade 
>>> object.
>> 
>> The RequestFacade is intended to protect the container from the 
>> application, right?
> 
> It can cut both ways.
> 
>> And they are (usually) re-used. If a RequestFacade object is
>> retained by the application and used later, a later 
>> client-request may be confused with the one the application was
>> expectin g> In the solution I presented, the facades are one-time
>> use and will stay dead once they are killed. The application
>> can't make a mistake and read a later client-request or write to
>> a later client-response.
> 
> Setting RECYCLE_FACADES=true does exactly that. Continued used by
> the app triggers an NPE since the underlying request/response is no
> longer there. Hence my question.

RequestFacade currently has a number of methods that perform
null-checks on the "request" member, but not all methods do this. Exampl
e:

@Override
public ServletContext getServletContext() {
if (request == null) {
throw new IllegalStateException(
sm.getString("requestFacade.nullRequest"));
}

return request.getServletContext();
}

Negative example:

@Override
public AsyncContext startAsync() throws IllegalStateException {
return request.startAsync();
}

Should these be aligned?

It seems to me that if recycleFacades="false" then there really isn't
any reason to wrap the request (response, etc.) in a facade object at
all, is there? Is there any opportunity to further reduce memory
footprint by just NOT creating these objects at all?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xQK4ACgkQHPApP6U8
pFjeYg/+MBc+iKgAtAmlf6D6MzgODhoGmGwibpPxsyssQ4jcmLPGUtwF/SVR5wtD
5QI+Nk3waVO0m9AUas0dSbEZnqYXrj0/yIqg2f8IpjKhwfayHfc0XQ7h+NMffK3o
WFpgFmIHb6L1nKBz7UCdLh4aAP4+AYzVH/yaw7aHNa1etZ4BH8CFcnEuzeaezU34
X5pYvP1vKtGae5kv5TuDKPll6UeA3xBSHhj6IJI8CSSwazPnOiwOITMPftCiAQ/3
qE4wR9AcYtdG8w+szAgpSIDkwqkEWGCTDtwxaTpfb4QZoxSCAcLRI8kYoUDkwV/u
lPgV647lM619r5yeEJ/aLaH/b11mr3dgWustu1+N7xupyosCLpgaRdbsr6ZBu+WY
ITalE2BSNMfjrV9RI45SVGfnWQ8RHzbmt9d5+oOyzo434zIx9pYY7IUEk8mSQ513
eb/D4Ap5BI2M2niOrVs6RnV9WEkvHdYq0/R23xO8LsmyyuAlBS3HuNrnK15z7Yva
a2FhZSSD7guPUXQWgB78HhabfhpvYSwVL/T5oghYMe3Q13Q6NMoY/lbzb7GEmZyr
FZy1sTnPXb0ScApqHVhKkXUgmWck/x/WDtsGf7NeGZV0uNQsLrdSURxCv1kbwlND
GajyDd4stFGPlJx5ycb7ci6vZqVqNGCTWgED/jPQNkGHGbiIgU4=
=Ygte
-END PGP SIGNATURE-

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

Re: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms

[Mark Thomas]

On 11/12/2019 17:43, Christopher Schultz wrote:



>> I'm not sure why we need this over and above the RequestFacade
>> object.
> 
> The RequestFacade is intended to protect the container from the
> application, right?

It can cut both ways.

> And they are (usually) re-used. If a RequestFacade
> object is retained by the application and used later, a later
> client-request may be confused with the one the application was expectin
> g>
> In the solution I presented, the facades are one-time use and will
> stay dead once they are killed. The application can't make a mistake
> and read a later client-request or write to a later client-response.

Setting RECYCLE_FACADES=true does exactly that. Continued used by the
app triggers an NPE since the underlying request/response is no longer
there. Hence my question.

Mark


> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xKskACgkQHPApP6U8
> pFhZyBAAtLxars/ZWmm5pRUkAg4yamIGLOflCBWE38j01NzGVmfibczkToyOkrIX
> qLRSzlLWQsX3x3559I5gD5o9KAwixBCO0M+oCCGzOAmnnmXVs7dPvTnLYJKrJMW0
> U811tR9cNpNAN+rrdLhafYe+O8gHNsbuAOwLOnePc3lt/Q1ze7/kNYLsKDnrt8GG
> lQKLE5Tv6mYr6tDnio9I9GjYnXP+G4swSvIL74o4swhzTLG5dzMAELOWtvBTBlPR
> MoZvM6T1vIizhYf8xMMOCJuyMVxHm4kbesAlgAVdaff1pCqf9UjezrM/j+g7H0m9
> 5t6bC13EB/uKKGvz6sb1zJHr3yPiX+KRdiRaL59X96oMlKEZhBlySD1fk7KldU6W
> 62N9u6l+TrrGG3aKOrIEPYLdIsMNrbPlPDirissnCygkFPMDRKNOjH9xs5CZqV1G
> aXI45uC9gUtC4wCdNnSYE+f+uosDdY7WYTWdru0GuDDod/iOOOxNfPbJAyqE8t1w
> G8KF+22rJvVxmehd78UL2LQtsYeOjLsZ2HJQAa7LwRZN+TCRhv2efJMIWncPbRuP
> GjVxnoRBrkvFSnGNoP2ZKqP0lN7Jrf470NWr4wQHD1r1P5p8Z4suilViS77gxpSK
> LQlO+bpl08BrOMY4f7+oRjeLA0FhwA8rNNc7LeTdxmud0LPN9Ro=
> =gHas
> -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: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/10/19 10:36, Mark Thomas wrote:
> On 10/12/2019 14:27, Christopher Schultz wrote:
> 
> 
> 
>> Would using org.apache.catalina.connector.RECYCLE_FACADES=true
>> have made this problem go away? Or would the behavior have been
>> the same, just less dangerous?
> 
> I think it would have triggered some NPEs in the background
> thread.
> 
>> I'm wondering if Tomcat could or should have another safety
>> feature to help catch this sort of thing in development. In all
>> my development environments, I have the JDBC connection pool size
>> set to a fixed maximum of 1 connection. This means that any
>> potential deadlocks in the application due to sloppy
>> connection-management will cause pretty early because we'll get
>> pool-fetch timeouts, missing-return-connection errors, etc.
>> 
>> Request object reuse has a measurable positive effect on
>> performance in production,
> 
> It would be worth confirming that is still the case for the Request
> and Response objects. I suspect it is but it would be good to get
> some recent, hard data.
> 
>> but in development probably doesn't matter quite so much. In the
>> same way that WebappClassLoader becomes inert when the 
>> application has been stopped, perhaps we could "shut-down"
>> request / response / session objects that have been loaned to a 
>> request-processor thread.
>> 
>> Something like this:
> 
> I'm not sure why we need this over and above the RequestFacade
> object.

The RequestFacade is intended to protect the container from the
application, right? And they are (usually) re-used. If a RequestFacade
object is retained by the application and used later, a later
client-request may be confused with the one the application was expectin
g.

In the solution I presented, the facades are one-time use and will
stay dead once they are killed. The application can't make a mistake
and read a later client-request or write to a later client-response.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xKskACgkQHPApP6U8
pFhZyBAAtLxars/ZWmm5pRUkAg4yamIGLOflCBWE38j01NzGVmfibczkToyOkrIX
qLRSzlLWQsX3x3559I5gD5o9KAwixBCO0M+oCCGzOAmnnmXVs7dPvTnLYJKrJMW0
U811tR9cNpNAN+rrdLhafYe+O8gHNsbuAOwLOnePc3lt/Q1ze7/kNYLsKDnrt8GG
lQKLE5Tv6mYr6tDnio9I9GjYnXP+G4swSvIL74o4swhzTLG5dzMAELOWtvBTBlPR
MoZvM6T1vIizhYf8xMMOCJuyMVxHm4kbesAlgAVdaff1pCqf9UjezrM/j+g7H0m9
5t6bC13EB/uKKGvz6sb1zJHr3yPiX+KRdiRaL59X96oMlKEZhBlySD1fk7KldU6W
62N9u6l+TrrGG3aKOrIEPYLdIsMNrbPlPDirissnCygkFPMDRKNOjH9xs5CZqV1G
aXI45uC9gUtC4wCdNnSYE+f+uosDdY7WYTWdru0GuDDod/iOOOxNfPbJAyqE8t1w
G8KF+22rJvVxmehd78UL2LQtsYeOjLsZ2HJQAa7LwRZN+TCRhv2efJMIWncPbRuP
GjVxnoRBrkvFSnGNoP2ZKqP0lN7Jrf470NWr4wQHD1r1P5p8Z4suilViS77gxpSK
LQlO+bpl08BrOMY4f7+oRjeLA0FhwA8rNNc7LeTdxmud0LPN9Ro=
=gHas
-END PGP SIGNATURE-

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

Re: Expected behavior of calling javax.servlet.ServletRequest#getInputStream after javax.servlet.http.HttpServletRequest#getPart

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 12/10/19 16:47, André Warnier (tomcat/perl) wrote:
> On 10.12.2019 15:31, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Behrang,
>> 
>> On 12/8/19 05:18, Behrang Saeedzadeh wrote:
>>> If I call javax.servlet.ServletRequest#getInputStream after
>>> having called javax.servlet.http.HttpServletRequest#getPart,
>>> even without performing any operations on the given part, I am
>>> getting an empty stream (0-bytes).
>>> 
>>> Is this in compliance with the spec?
>> 
>> What does the servlet spec say about that situation?
>> 
> 
> A bit in defense of the OP, I have to say that the Servlet Spec
> (4.0 final) does not seem extremely clear on that subject.

While I appreciate your research activities, I was hoping the OP would
actually read the spec to get some clarification.

> In section "3.1.1 When Parameters Are Available", it /does/ say
> this :
> 
> "If the conditions are met, post form data will no longer be
> available for reading directly from the request object’s input
> stream."
> 
> But among those conditions that have to be met (just above that
> quote) is "4. The servlet has made an initial call of any of the
> "getParameter family" of methods on the request object."
> 
> (So there, it talks about "the getParameter family", not the
> "getPart" ones).
> 
> It only talks about the "getPart" methods in the next section "3.2
> File upload", and in that section, all it says about the input
> stream is : "If the servlet container does not provide the
> multi-part/form-data processing, the data will be available through
> the HttpServletReuqest.getInputStream."
> 
> So the way I read this, is that there is nothing that explicitly
> says that the InputStream is no longer available if you have called
> "getPart".

The only reason the container would process multi-part/form-data
requests is if you called request.getPart*. Therefore, the InputStream
is no longer available.

> (It is also in fact not very clear about what happens to the
> parameters, when the content-type of the Request is
> "multipart/form-data", which is only mentioned in section 3.2.)

Normal parameters are available via request.getParameter*. You can
also go through the agony of getPart("foo").getInputStream() if you'd
like. This is documented in section 3.2 "File Upload".

> On the other hand, 
> http://tomcat.apache.org/tomcat-9.0-doc/servletapi/index.html -->
> Interface HttpServletRequest says :
> 
> Part getPart(java.lang.String name) throws java.io.IOException, 
> ServletException Gets the named Part or null if the Part does not
> exist. *Triggers upload of all Parts*. (emphasis mine)
> 
> which /may/ be taken to mean (and probably does) that it consumes
> the whole InputStream.

It does. And, necessarily, it must. You can't find out what's in the
request entity without ... reading the request entity.

> But again, this may be lacking some overall clarity.
> 
> In any case, the OP's question is not really unwarranted, unless
> there is some other explanation somewhere which I have missed.

I guess to me this falls under the category of "obvious", but then
again I know quite a bit about this subject.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xJ+IACgkQHPApP6U8
pFj+aQ//eGoRadiIjoP5uG3e9rzwjK8JqL6aa39UIz0iQH3rgXGpQBAJf2u0QBwJ
8qjFVG8PpJV6yIrcLK8IxbrgJyKTeBsvxZc6/F092w1lU2ScHr96qSNJQFVyw94J
YQUZezyP2yVn6SHcm5Ok6lLnf/wo2Nf527ritAkAmrNg31pnEPa89giCJFKzIUkm
OJj82MZ8CoLmaL4u0gV4Ad5AghasCNASvrnTuc7BAh8COWDBOqHFpKc7esrHzilw
R8uBHJJ5cHujPQPcHTpMeeSWFUOo6IU+LUi91KxYM6ROjZIb+74e6Pi0fpIVPWAk
ycukcRPJKKGAucjDzst8TSwVsJZ659Q77UKp8PaIMms2s5njZvOwrXsTn0ZGF/uI
PLUISkt+jbj0o/EMYJdsanVfE4ZsZXA4JSDXXiCwOAswccRluMgkLEJxQsrsRac1
rfsWvUYqqIchTpfOSc/K0UgR4hcMIewiaF0FU0qru0eZfk6ErWVr7Pvnc6w+HkU6
TzYxFnHY03+LZsCvu8lYDysKgNg5/ibrklyekTkebmBgSMV7LuR9ewM12X7Yqmvw
ABhyNt8hRKHJx7yY4kg1WozwtIc+MhAWCVhKqetZzvc9E+KQbYcJHxiGOmuop5cJ
oWnhGSQbWPx6xOqtgvWczDfJfgwCBm4UAeIn5W/62KVG7EuukfA=
=fdap
-END PGP SIGNATURE-

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

Re: remote jmx monitoring through ssh tunnel

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12/10/19 12:59, Chris Cheshire wrote:
> On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire
>  wrote:
>> 
>> On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz 
>>  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Chris,
>>> 
>>> On 12/9/19 17:10, Chris Cheshire wrote:
 In CATALINA_BASE/bin/setenv.sh I have the following :
 
 CATALINA_OPTS="-Dcom.sun.management.jmxremote 
 -Dcom.sun.management.jmxremote.ssl=false 
 -Dcom.sun.management.jmxremote.authenticate=false"
>>> 
>>> Okay.
>>> 
 In CATALINA_BASE/conf/server.xml I have a listener configured
 :
 
 >>> className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"

 
rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
 useLocalPorts="true" />
 
 
 Upon startup I see in logs : INFO [main] 
 org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer

 
The JMX Remote Listener has configured the registry on port
 [10001] and the server on port [10002] for the [Platform]
 server
 
 
 $ netstat -an | grep 10001 tcp4   0  0
 127.0.0.1.10001 *.*LISTEN tcp6   0
 0  ::1.10001 *.*LISTEN
 
 On my local machine I have a tunnel set up as follows : ssh
 -N -L10001:localhost:10001 -L10002:localhost:10002
 user@remotehost
 
 (where user is the user tomcat is running under)
 
 When I try to add a remote JMX connection in VisualVM on my
 client machine to localhost:10001 I get an error dialog after
 a brief delay with the message "Cannot connect to
 localhost:10001 using 
 service:jmx:rmi:///jndi/rmi://localhost:10001/jmxrmi". If I
 change it to port 10002 I get the same error. On the server
 at this time : $ netstat -an | grep 10001 tcp4   0  0
 127.0.0.1.10001 *.*LISTEN tcp6   0
 0  ::1.10001 *.*LISTEN tcp4   0
 0  127.0.0.1.62637 127.0.0.1.10001TIME_WAIT
 
 
 If I try to use jconsole connecting to port 10001 I get the
 error "Connection failed: non-JRMP server at remote
 endpoint". Connecting to port 10002 I get the error
 "Connection failed: no such object in table"
>>> 
>>> You should be using the port defined by
>>> rmiRegistryPortPlatform, so 10001 is the correct port to use.
>>> 
 I've been through the tomcat configuration documentation a
 couple times but I can't see what else I need to configure.
>>> 
>>> What you have looks good to me without reproducing it myself.
>>> Can you do :
>>> 
>>> $ netstat -an | grep 1000[0-9]
>>> 
>>> ?
>>> 
>>> Just to be sure about both ports?
>>> 
>> 
>> $ netstat -an | grep 1000[0-9] tcp6   0  0 :::10001
>> :::*LISTEN tcp6   0  0 :::10002
>> :::*LISTEN
>> 
>> 
>> H. Tomcat is only listening on ipv6 ports, but my tunnel is
>> using ipv4. After digging around [1], I added this to
>> CATALINA_OPTS in setenv.sh
>> 
>> -Djava.net.preferIPv4Stack=true
>> -Djava.net.preferIPv4Addresses=true
>> 
>> $ netstat -an | grep 1000[0-9] tcp0  0 0.0.0.0:10001
>> 0.0.0.0:*   LISTEN tcp0  0 0.0.0.0:10002
>> 0.0.0.0:*   LISTEN
>> 
>> When I try to connect with jconsole I get the same error
>> (non-JRMP server at remote endpoint), with the server showing
>> 
>> tcp0  0 0.0.0.0:10001   0.0.0.0:*
>> LISTEN tcp0  0 0.0.0.0:10002   0.0.0.0:*
>> LISTEN tcp0  0 127.0.0.1:10001
>> 127.0.0.1:43803 TIME_WAIT tcp0  0
>> 127.0.0.1:10001 127.0.0.1:43815 TIME_WAIT
>> 
>> 
>> I have also updated sshd_config with
>> 
>> PermitTunnel yes
>> 
>> and restarted that. Still no change.
>> 
>> Chris
>> 
>> 
>> [1]
>> https://serverfault.com/questions/390840/how-does-one-get-tomcat-to-b
ind-to-ipv4-address
>
>> 
> 
> As a followup to take the tunnel out of the equation I downloaded 
> jmxterm [1] on the server and tried to connect
> 
> 
> $ java -jar jmxterm-1.0.0-uber.jar Welcome to JMX terminal. Type
> "help" for available commands. $>open localhost:10001 
> #RuntimeIOException: Runtime IO exception: Failed to retrieve 
> RMIServer stub: javax.naming.CommunicationException [Root exception
> is java.rmi.ConnectIOException: non-JRMP server at remote
> endpoint] $>
> 
> 
> Back to the tomcat documentation, I added this to CATALINA_OPTS 
> (based on listener config and assumed defaults)
> 
> -Dcom.sun.management.jmxremote.registry.ssl=false
> 
> and now I get a different error : $>open localhost:10001 
> #RuntimeIOException: Runtime IO exception: Failed to retrieve 
> RMIServer stub: javax.naming.CommunicationException [Root exception
> is java.rmi.UnmarshalException: error unmarshalling return; nested 
> exception is: java.lang.ClassNotFoundException: 
> 

Re: HTTP/2 configuration

[Mark Thomas]

On December 11, 2019 11:54:40 AM UTC, "M. Manna"  wrote:
>Mark,
>
>On Wed, 11 Dec 2019 at 11:48, Mark Thomas  wrote:
>
>> All,
>>
>> The Tomcat committers are looking for some user feedback.
>>
>> Currently, the HTTP/2 protocol configuration [1] duplicates many
>> attributes of the HTTP/1.1 protocol [2] it is nested under.
>>
>> We are considering simplifying this for Tomcat 10 onwards and having
>the
>> HTTP/2 protocol simply inherit the settings from HTTP/1.1.
>Optionally,
>> we could have HTTP/2 inherit from HTTP/1.1 by default but allow an
>> HTTP/2 specific override if required. However, this adds quite a few
>> edge cases and I can't think of a use case where, for example, you'd
>> want to have different maxHeaderCount settings on HTTP/1.1 and
>HTTP/2.
>>
>  Inheritance seems to be an easier choice.

From an implementation perspective it is not easier. It also adds complexity on 
the usage as the behaviour, particular runtime changes, may not be obvious.

> Would this mean various
>connectors
>might then be using a "Factory"-like (insted of specific
>Http11*Protocol)
>to refer to the correct underlying protocol?

No.

Mark

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

Re: HTTP/2 configuration

[M. Manna]

Mark,

On Wed, 11 Dec 2019 at 11:48, Mark Thomas  wrote:

> All,
>
> The Tomcat committers are looking for some user feedback.
>
> Currently, the HTTP/2 protocol configuration [1] duplicates many
> attributes of the HTTP/1.1 protocol [2] it is nested under.
>
> We are considering simplifying this for Tomcat 10 onwards and having the
> HTTP/2 protocol simply inherit the settings from HTTP/1.1. Optionally,
> we could have HTTP/2 inherit from HTTP/1.1 by default but allow an
> HTTP/2 specific override if required. However, this adds quite a few
> edge cases and I can't think of a use case where, for example, you'd
> want to have different maxHeaderCount settings on HTTP/1.1 and HTTP/2.
>
>  Inheritance seems to be an easier choice. Would this mean various
connectors
might then be using a "Factory"-like (insted of specific Http11*Protocol)
to refer to the correct underlying protocol?

> So, users, what do you think?
>
> Mark
>
>
>
> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
> [2] http://tomcat.apache.org/tomcat-9.0-doc/config/http.html
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

HTTP/2 configuration

[Mark Thomas]

All,

The Tomcat committers are looking for some user feedback.

Currently, the HTTP/2 protocol configuration [1] duplicates many
attributes of the HTTP/1.1 protocol [2] it is nested under.

We are considering simplifying this for Tomcat 10 onwards and having the
HTTP/2 protocol simply inherit the settings from HTTP/1.1. Optionally,
we could have HTTP/2 inherit from HTTP/1.1 by default but allow an
HTTP/2 specific override if required. However, this adds quite a few
edge cases and I can't think of a use case where, for example, you'd
want to have different maxHeaderCount settings on HTTP/1.1 and HTTP/2.

So, users, what do you think?

Mark



[1] http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
[2] http://tomcat.apache.org/tomcat-9.0-doc/config/http.html


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

Re: Expected behavior of calling javax.servlet.ServletRequest#getInputStream after javax.servlet.http.HttpServletRequest#getPart

[Konstantin Kolinko]

ср, 11 дек. 2019 г. в 13:06, Behrang Saeedzadeh :
>
> Thanks Andre for explaining it much better than I did.
>
> I posted this to Jakarta EE's mailing list too:
> https://www.eclipse.org/lists/jakarta.ee-community/msg01477.html
>
> I think at least the JavaDocs comments and the spec need minor amendments
> to document this expected behaviour clearly.

javax.servlet.ServletRequest#getInputStream() and getParameter()
methods address different use cases. It is rather unusual to try
calling getInputStream() when the Content-Type of the request is the
one handled by parameter parsing.

It is possible to use both getParameter() and getInputStream() if
request body has content-type that is not processed by parameter
parsing. In this case getParameter() returns the parameters parsed
from the query string of the request line and does not process the
body.


E.g. in Tomcat Manager web application it is possible to send a WAR
file in the body of a PUT request. The context path for the uploaded
web application is specified by a parameter in the request URL. Both
getParameter() and getInputStream() are used here.

http://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html#Deploy_A_New_Application_Archive_(WAR)_Remotely

I think that changing the method getInputStream() to throw an
IllegalStateException (e.g. as a vendor-specific option) may help
developers to detect their programming errors, but does not address
any real use case. On the good side, it also means that it does not
break any real use case.

Best regards,
Konstantin Kolinko

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

Re: Expected behavior of calling javax.servlet.ServletRequest#getInputStream after javax.servlet.http.HttpServletRequest#getPart

[Behrang Saeedzadeh]

Thanks Andre for explaining it much better than I did.

I posted this to Jakarta EE's mailing list too:
https://www.eclipse.org/lists/jakarta.ee-community/msg01477.html

I think at least the JavaDocs comments and the spec need minor amendments
to document this expected behaviour clearly.

Best regards,

{
  "blog" :
"https://blog.behrang.org;,
  "twitter":
 "https://twitter.com/behrangsa;,
  "github":
 "https://github.com/behrangsa/;,
  "stackoverflow":
 "https://stackoverflow.com/users/309683?tab=profile"}



On Wed, Dec 11, 2019 at 8:47 AM André Warnier (tomcat/perl) 
wrote:

> On 10.12.2019 15:31, Christopher Schultz wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Behrang,
> >
> > On 12/8/19 05:18, Behrang Saeedzadeh wrote:
> >> If I call javax.servlet.ServletRequest#getInputStream after having
> >> called javax.servlet.http.HttpServletRequest#getPart, even without
> >> performing any operations on the given part, I am getting an empty
> >> stream (0-bytes).
> >>
> >> Is this in compliance with the spec?
> >
> > What does the servlet spec say about that situation?
> >
>
> A bit in defense of the OP, I have to say that the Servlet Spec (4.0
> final) does not seem
> extremely clear on that subject.
> In section "3.1.1 When Parameters Are Available", it /does/ say this :
>
> "If the conditions are met, post form data will no longer be available for
> reading directly from the request object’s input stream."
>
> But among those conditions that have to be met (just above that quote) is
> "4. The servlet has made an initial call of any of the "getParameter
> family" of methods
> on the request object."
>
> (So there, it talks about "the getParameter family", not the "getPart"
> ones).
>
> It only talks about the "getPart" methods in the next section "3.2 File
> upload", and in
> that section, all it says about the input stream is :
> "If the servlet container does not provide the multi-part/form-data
> processing,
> the data will be available through the HttpServletReuqest.getInputStream."
>
> So the way I read this, is that there is nothing that explicitly says that
> the InputStream
> is no longer available if you have called "getPart".
>
> (It is also in fact not very clear about what happens to the parameters,
> when the
> content-type of the Request is "multipart/form-data", which is only
> mentioned in section 3.2.)
>
> On the other hand,
> http://tomcat.apache.org/tomcat-9.0-doc/servletapi/index.html
> --> Interface HttpServletRequest
> says :
>
> Part getPart(java.lang.String name)
>throws java.io.IOException,
>   ServletException
> Gets the named Part or null if the Part does not exist. *Triggers upload
> of all Parts*.
> (emphasis mine)
>
> which /may/ be taken to mean (and probably does) that it consumes the
> whole InputStream.
>
> But again, this may be lacking some overall clarity.
>
> In any case, the OP's question is not really unwarranted, unless there is
> some other
> explanation somewhere which I have missed.
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>