IPV6

2017-06-13 Thread Vivek Shende 
Hello

I am having below query for tomcat 8.5.15 version. Please help.

I am using tomcat 8.5.15 and my network is supporting both ipv4 and ipv6
address stacks. However, I want tomcat to listen to only ipv6 address (not
ipv4).

I was trying to find the solution on google and reached to tomcat's manual
- http://library.bec.ac.in/docs/config/http.html. On this page, the address
attribute description says --->

For servers with more than one IP address, this attribute specifies which
address will be used for listening on the specified port. By default, the
connector will listen all local addresses. Unless the JVM is configured
otherwise using system properties, the Java based connectors (NIO, NIO2)
will listen on both IPv4 and IPv6 addresses when configured with either
0.0.0.0 or ::. The APR/native connector will only listen on IPv4 addresses
if configured with 0.0.0.0 and will listen on IPv6 addresses (and
optionally IPv4 addresses depending on the setting of ipv6onlyv6) if
configured with ::.

According to above description, with the use of ipv6onlyv6, tomcat will
listen only on ipv6 address,  I tried below combination --

**

Above combination worked flawlessly in windows machine. but when I am using
the combination in linux suse, it's not working. This combination is not
blocking ipv4 address stack, in linux suse. Tomcat is listening to both
ipv6 and ipv4 address stacks.

Below is linux system details (via uname -a) --

Linux ip-10-1-29-39.ec2.internal 3.12.49-1-default #1 SMP Fri Dec 11
11:36:56 UTC 2015 (6571a4b) x86_64 x86_64 x86_64 GNU/Linux

Re: AsynContext.dispatch() with encoded URI

2017-06-13 Thread Rossen Stoyanchev 
Issue created https://bz.apache.org/bugzilla/show_bug.cgi?id=61185.

On Tue, Jun 13, 2017 at 6:25 PM, Mark Thomas  wrote:

> On 13/06/17 21:30, Rossen Stoyanchev wrote:
> > hi,
> >
> > The spec says:
> >
> > "If the AsyncContext was initialized via the startAsync(ServletRequest,
> > ServletResponse) and the request passed is an instance of
> > HttpServletRequest , then the dispatch is to the URI returned by
> > HttpServletRequest.getRequestURI()"
> >
> > However AsyncContextImpl seems to be using the servletPath:
> > https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff8
> 02d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163
> >
> > So given a URL with an encoded slash (and
> > UDecoder.ALLOW_ENCODED_SLASH=true):
> > /foo/vv%2F1234/add/2
> >
> > The dispatch ends up going to:
> > /foo/vv/1234/add/2
> >
> > Is this intentional? It contradicts the spec.
>
> The commit that introduced this change is:
> https://svn.apache.org/viewvc?view=revision=1497474
>
> The fix to ServletRequest.getContextPath() was made a little later:
> https://svn.apache.org/viewvc?view=revision=1593621
>
> This looks like a fairly minor bug that should be an easy fix. Please
> open a bugzilla issue for this.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: AsynContext.dispatch() with encoded URI

2017-06-13 Thread Mark Thomas 
On 13/06/17 21:30, Rossen Stoyanchev wrote:
> hi,
> 
> The spec says:
> 
> "If the AsyncContext was initialized via the startAsync(ServletRequest,
> ServletResponse) and the request passed is an instance of
> HttpServletRequest , then the dispatch is to the URI returned by
> HttpServletRequest.getRequestURI()"
> 
> However AsyncContextImpl seems to be using the servletPath:
> https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163
> 
> So given a URL with an encoded slash (and
> UDecoder.ALLOW_ENCODED_SLASH=true):
> /foo/vv%2F1234/add/2
> 
> The dispatch ends up going to:
> /foo/vv/1234/add/2
> 
> Is this intentional? It contradicts the spec.

The commit that introduced this change is:
https://svn.apache.org/viewvc?view=revision=1497474

The fix to ServletRequest.getContextPath() was made a little later:
https://svn.apache.org/viewvc?view=revision=1593621

This looks like a fairly minor bug that should be an easy fix. Please
open a bugzilla issue for this.

Mark

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

Re: tomcat 7, null tag attributes

2017-06-13 Thread Mark Thomas 
On 13/06/17 22:01, Mark Thomas wrote:
> On 13/06/17 15:27, Chris Cheshire wrote:



>> I'm bewildered at why tomcat operates this way when it comes to Numbers and
>> Strings. Why is it insistent on coercion when null and zero are absolutely
>> not the same value.  If this is because of autoboxing, then isn't that a
>> bug? A long is not a Long, and when tag attributes must be objects and not
>> atomic types, shouldn't they be treated accordingly?
> 
> Tomcat behaves this way because the specification says it has to. Plenty
> of folks disagree strongly with the specification but Tomcat has to
> implement it. COERCE_TO_ZERO is a specification breaking configuration
> option to workaround this particular behaviour.
> 
> I've been digging in to this some more and it appears that
> COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat.
> The test case you present above behaves the way you want with
> COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why
> that wider scope wasn't applied to 7.0.x.

Mystery solved thanks to some svn archaeology and cross-referencing to
the relevant specs.

Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and null to 0
for numeric types (section 1.18.3). (As did earlier versions of the EL
spec).

Initially there weren't many complaints because the coercion rules
weren't implemented correctly in one important case (i.e. they left
these as null rather than coercing to zero). Then bug 43285 [1] got
fixed and the complaints started.

To address the complaints, Tomcat introduced the system property
org.apache.el.parser.COERCE_TO_ZERO which restored the non-specification
compliant behaviour for the one coercion case that was causing problems.
To align with the EL 2.2. specification, the default was for coercion to
zero to occur.

The level of complaints about the coercion rules was such that a
backwards compatible change was introduced in EL 3.0 to not coerce to
zero. Given Java EE's normal approach that backwards compatibility
concerns trump all others, it is a sign of the seriousness with which
the issue was taken that an incompatible change was made.

Tomcat 8, which implemented EL 3.0, switched to the new coercion rules.
To help migration of 7.0.x applications, the role of COERCE_TO_ZERO was
expanded to cover all instances of EL coercion. To align with EL 3.0,
the default was changed not to coerce to zero.

Which brings us to where we are today.

The problem you are seeing is a spec compliant coercion that is not
covered by the COERCE_TO_ZERO property in 7.0.x.

There are several possible solutions:

1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x)
   I appreciate that an RPM is not available for Tomcat 8 but 8.0.x has
   had stable releases for three years and 8.5.x for 1 year.

2. Use one of the workarounds. All pretty ugly.

3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x to be
   equivalent to the scope in 8.0.x. At this stage in the 7.0.x that is
   unlikely to happen. The risk of breakage for other users is too
   great.

4. Lobby for an additional configuration option for 7.0.x that extends
   the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent to the
   scope in 8.0.x. This should be doable with care (there was some
   refactoring involved in the scope change that would need careful
   back-porting). This is also dependent on the CentOS distribution
   picking up the change to 7.0.x. I don't know how likely that is.
   Given the current package is based on a version over a year old I
   suspect that the changes of this being quick are very low.

None of those options look ideal. I'd probably go with 1 but my
familiarity with Tomcat is such that I usually prefer to work with an
ASF distribution rather than a downstream one anyway. YMMV.

Mark


[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285

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

Re: tomcat 7, null tag attributes

2017-06-13 Thread Mark Thomas 
On 13/06/17 15:27, Chris Cheshire wrote:
> On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas  wrote:
> 
>> On 31/05/17 23:31, Chris Cheshire wrote:
>>> I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag
>>> attributes of type Long/Integer/Float, however it is *always* coerced to
>>> zero.
>>>
>>> <%@attribute name="parentId" required="true" rtexprvalue="true"
>>> type="java.lang.Long" %>
>>>
>>> Changing required to false does nothing. I tried setting the system
>>> property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf
>>> (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS)
>> but
>>> this does nothing.
>>
>> As expected. That system property only affects evaluation of EL
>> expressions.
>>
>>
> But isn't  evaluation of an EL expression? Why is
> it treated differently than the evaluation of ${val} when it is used in the
> same scope as it is declared/assigned?
> 
> For instance, this tests in a JSP :
> 
> 
> l is null

value in the set tag has the type object doesn't it? That would explain
the lack of coercion.


> 
> will succeed.
> 
> The moment I pass l into a tag and try the exact same evaluation inside, it
> fails because it has been coerced to 0.
> 
> 
>>
>>> How do I pass a null Long/Float/Integer as a tag attribute and have it
>> kept
>>> as null and not turned into an incorrect value?
>>
>> Use parentId="<%=null%>" rather than parentId=""
>>
>> Ugly, but it does the job. Scriplets aren't coerced.
>>
>> Mark
>>
> 
> 
> I can't use that because I'm not trying to pass the value null, rather a
> variable that possibly equates to null.
> 
> Also, if I have a custom bean
> 
> public class Foo {
>   private Long val;
> 
>   public Foo() { }
>   public Long getVal() { return val; }
>   public void setVal(Long val) { this.val = val; }
> }
> 
> and I pass an instance of Foo into a tag, then val stays as null.
> 
> It seems the only solutions are to use a sentinel value that "shouldn't"
> get used (cringeworthy in its own right), or to wrap everything in a custom
> bean (also extremely ugly).
> 
> I'm bewildered at why tomcat operates this way when it comes to Numbers and
> Strings. Why is it insistent on coercion when null and zero are absolutely
> not the same value.  If this is because of autoboxing, then isn't that a
> bug? A long is not a Long, and when tag attributes must be objects and not
> atomic types, shouldn't they be treated accordingly?

Tomcat behaves this way because the specification says it has to. Plenty
of folks disagree strongly with the specification but Tomcat has to
implement it. COERCE_TO_ZERO is a specification breaking configuration
option to workaround this particular behaviour.

I've been digging in to this some more and it appears that
COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat.
The test case you present above behaves the way you want with
COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why
that wider scope wasn't applied to 7.0.x.

Mark

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

AsynContext.dispatch() with encoded URI

2017-06-13 Thread Rossen Stoyanchev 
hi,

The spec says:

"If the AsyncContext was initialized via the startAsync(ServletRequest,
ServletResponse) and the request passed is an instance of
HttpServletRequest , then the dispatch is to the URI returned by
HttpServletRequest.getRequestURI()"

However AsyncContextImpl seems to be using the servletPath:
https://github.com/apache/tomcat/blob/9af8708d7ea3817df47f34146a6ff802d96980fa/java/org/apache/catalina/core/AsyncContextImpl.java#L156-L163

So given a URL with an encoded slash (and
UDecoder.ALLOW_ENCODED_SLASH=true):
/foo/vv%2F1234/add/2

The dispatch ends up going to:
/foo/vv/1234/add/2

Is this intentional? It contradicts the spec.

Thanks,
Rossen

Re: [OT] tomcat 7, null tag attributes

2017-06-13 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Naga,

Please don't hijack threads. If you wish to ask a question, please
post a new message (don't REPLY to an old one) to the list.

Thanks,
- -chris

On 6/13/17 1:00 PM, Naga Ramesh wrote:
> All,
> 
> As of now we are using the below parameters for tomcat8 version on 
> production environment, please recheck and confirm, these are fine 
> or anything need to add or change.
> 
> Please confirm me.
> 
> export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m" export 
> CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m" export 
> CATALINA_OPTS="$CATALINA_OPTS -server" export
> JAVA_OPTS="$JAVA_OPTS -Xverify:none" export
> CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation
> -XX:+AggressiveOpts -XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2
> -XX:MaxTenuringThreshold=15 -XX:+UseTLAB -XX:G1HeapRegionSize=32m
> -XX:-UseAdaptiveSizePolicy -XX:MaxMetaspaceSize=512m
> -XX:-UseSplitVerifier "
> 
> 
> 
> -Original Message- From: Chris Cheshire 
> [mailto:yahoono...@gmail.com] Sent: Tuesday, June 13, 2017 7:58 PM
>  To: Tomcat Users List Subject: Re: tomcat 7, null tag attributes
> 
> On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas  
> wrote:
> 
>> On 31/05/17 23:31, Chris Cheshire wrote:
>>> I am using tomcat 7 on CentOS 7 and I need to pass a null
>>> value to tag attributes of type Long/Integer/Float, however it
>>> is *always* coerced to zero.
>>> 
>>> <%@attribute name="parentId" required="true" rtexprvalue="true"
>>> type="java.lang.Long" %>
>>> 
>>> Changing required to false does nothing. I tried setting the 
>>> system property org.apache.el.parser.COERCE_TO_ZERO to false
>>> in tomcat.conf (-Dorg.apache.el.parser.COERCE_TO_ZERO=false
>>> with my other JAVA_OPTS)
>> but
>>> this does nothing.
>> 
>> As expected. That system property only affects evaluation of EL 
>> expressions.
>> 
>> 
> But isn't  evaluation of an EL 
> expression? Why is it treated differently than the evaluation of 
> ${val} when it is used in the same scope as it is 
> declared/assigned?
> 
> For instance, this tests in a JSP :
> 
>  l is null
> 
> will succeed.
> 
> The moment I pass l into a tag and try the exact same evaluation 
> inside, it fails because it has been coerced to 0.
> 
> 
>> 
>>> How do I pass a null Long/Float/Integer as a tag attribute and 
>>> have it
>> kept
>>> as null and not turned into an incorrect value?
>> 
>> Use parentId="<%=null%>" rather than parentId=""
>> 
>> Ugly, but it does the job. Scriplets aren't coerced.
>> 
>> Mark
>> 
> 
> 
> I can't use that because I'm not trying to pass the value null, 
> rather a variable that possibly equates to null.
> 
> Also, if I have a custom bean
> 
> public class Foo { private Long val;
> 
> public Foo() { } public Long getVal() { return val; } public void 
> setVal(Long val) { this.val = val; } }
> 
> and I pass an instance of Foo into a tag, then val stays as null.
> 
> It seems the only solutions are to use a sentinel value that 
> "shouldn't" get used (cringeworthy in its own right), or to wrap 
> everything in a custom bean (also extremely ugly).
> 
> I'm bewildered at why tomcat operates this way when it comes to 
> Numbers and Strings. Why is it insistent on coercion when null and 
> zero are absolutely not the same value.  If this is because of 
> autoboxing, then isn't that a bug? A long is not a Long, and when 
> tag attributes must be objects and not atomic types, shouldn't
> they be treated accordingly?
> 
> 
> Chris
> 
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZQCtVAAoJEBzwKT+lPKRYqm0QAIC1onD6dKSqA8FBiD2hfSF+
fGM2hQ6j7nWQPQXT8DogrreL8Dhc2u0RU6jllMBh1mMuYOpLa51iWZz3MQpS6bx1
28CcwlHpb04TH4FBzan1a1ENxwWGFqrpzx4tltRmZy6LHi2/ElNcljMIfOcKBE53
qMSUxH8erBamRwXliYBKlTuTNzLdkhqC2tJ3eWwJ4m8vdXg2zHZ9R3crSBqUZB4y
NoiOMnr4LO8NMJJp1obI27fLsBf6CnYPSPYFzjqPoXCSe+gk7E0VG47+MOEl2l/K
Yu4ZrkmFqsPlwoSjrKuQVcsvERKb8vxJKn9180UweI2WVgzuxhJLUjtuXzjsat6O
hyhQk623a33chKmpK9KJV1t2c5p/MzrPqBf+ZoOUHeXUWtwHA/QHqDWxvs4t/9+k
UPYy0PxrNLu29UzbRDXuc0CRXq463jHyA/UpnJano35lc5sIKeJb12LijHcvxNfT
5GgGGIHFzM7NEW3TAXzwkSWofGK2lri99qYU+/IJOA8L+1QLFhnn1JEXHsgJXeRs
XwP/6VQJv4gupOSk9V3LVfztmlY9H/y+Rba0pMqqj/qulo6QJ4rRhykFrX79KFXr
cnCzJsBOzxyN+mz9XHwPYluQaCTRfYz1OnEeWKaOs1L9Fi+ZC0oCjiWRE2KM8IwD
4deH3ritpTrr5PDGaKyX
=ZZuh
-END PGP SIGNATURE-

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

RE: tomcat 7, null tag attributes

2017-06-13 Thread Naga Ramesh 
All,

As of now we are using the below parameters for tomcat8 version on production 
environment, please recheck and confirm, these are fine or anything need to add 
or change.

Please confirm me.

export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -server"
export JAVA_OPTS="$JAVA_OPTS  -Xverify:none"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation -XX:+AggressiveOpts 
-XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2 -XX:MaxTenuringThreshold=15 
-XX:+UseTLAB
 -XX:G1HeapRegionSize=32m -XX:-UseAdaptiveSizePolicy -XX:MaxMetaspaceSize=512m 
-XX:-UseSplitVerifier "



-Original Message-
From: Chris Cheshire [mailto:yahoono...@gmail.com] 
Sent: Tuesday, June 13, 2017 7:58 PM
To: Tomcat Users List
Subject: Re: tomcat 7, null tag attributes

On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas  wrote:

> On 31/05/17 23:31, Chris Cheshire wrote:
> > I am using tomcat 7 on CentOS 7 and I need to pass a null value to 
> > tag attributes of type Long/Integer/Float, however it is *always* 
> > coerced to zero.
> >
> > <%@attribute name="parentId" required="true" rtexprvalue="true"
> > type="java.lang.Long" %>
> >
> > Changing required to false does nothing. I tried setting the system 
> > property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf 
> > (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other 
> > JAVA_OPTS)
> but
> > this does nothing.
>
> As expected. That system property only affects evaluation of EL 
> expressions.
>
>
But isn't  evaluation of an EL expression? Why is it 
treated differently than the evaluation of ${val} when it is used in the same 
scope as it is declared/assigned?

For instance, this tests in a JSP :


l is null

will succeed.

The moment I pass l into a tag and try the exact same evaluation inside, it 
fails because it has been coerced to 0.


>
> > How do I pass a null Long/Float/Integer as a tag attribute and have 
> > it
> kept
> > as null and not turned into an incorrect value?
>
> Use parentId="<%=null%>" rather than parentId=""
>
> Ugly, but it does the job. Scriplets aren't coerced.
>
> Mark
>


I can't use that because I'm not trying to pass the value null, rather a 
variable that possibly equates to null.

Also, if I have a custom bean

public class Foo {
  private Long val;

  public Foo() { }
  public Long getVal() { return val; }
  public void setVal(Long val) { this.val = val; } }

and I pass an instance of Foo into a tag, then val stays as null.

It seems the only solutions are to use a sentinel value that "shouldn't"
get used (cringeworthy in its own right), or to wrap everything in a custom 
bean (also extremely ugly).

I'm bewildered at why tomcat operates this way when it comes to Numbers and 
Strings. Why is it insistent on coercion when null and zero are absolutely not 
the same value.  If this is because of autoboxing, then isn't that a bug? A 
long is not a Long, and when tag attributes must be objects and not atomic 
types, shouldn't they be treated accordingly?


Chris


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

Re: tomcat 7, null tag attributes

2017-06-13 Thread Chris Cheshire 
On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas  wrote:

> On 31/05/17 23:31, Chris Cheshire wrote:
> > I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag
> > attributes of type Long/Integer/Float, however it is *always* coerced to
> > zero.
> >
> > <%@attribute name="parentId" required="true" rtexprvalue="true"
> > type="java.lang.Long" %>
> >
> > Changing required to false does nothing. I tried setting the system
> > property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf
> > (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS)
> but
> > this does nothing.
>
> As expected. That system property only affects evaluation of EL
> expressions.
>
>
But isn't  evaluation of an EL expression? Why is
it treated differently than the evaluation of ${val} when it is used in the
same scope as it is declared/assigned?

For instance, this tests in a JSP :


l is null

will succeed.

The moment I pass l into a tag and try the exact same evaluation inside, it
fails because it has been coerced to 0.


>
> > How do I pass a null Long/Float/Integer as a tag attribute and have it
> kept
> > as null and not turned into an incorrect value?
>
> Use parentId="<%=null%>" rather than parentId=""
>
> Ugly, but it does the job. Scriplets aren't coerced.
>
> Mark
>


I can't use that because I'm not trying to pass the value null, rather a
variable that possibly equates to null.

Also, if I have a custom bean

public class Foo {
  private Long val;

  public Foo() { }
  public Long getVal() { return val; }
  public void setVal(Long val) { this.val = val; }
}

and I pass an instance of Foo into a tag, then val stays as null.

It seems the only solutions are to use a sentinel value that "shouldn't"
get used (cringeworthy in its own right), or to wrap everything in a custom
bean (also extremely ugly).

I'm bewildered at why tomcat operates this way when it comes to Numbers and
Strings. Why is it insistent on coercion when null and zero are absolutely
not the same value.  If this is because of autoboxing, then isn't that a
bug? A long is not a Long, and when tag attributes must be objects and not
atomic types, shouldn't they be treated accordingly?


Chris

Re: AW: JVM Crash in tcnative due to concurrency/timing in HTTP/2

2017-06-13 Thread Mark Thomas 
On 13/06/17 10:13, Kreuser, Peter wrote:
> Mark,
> 
>> On 09/06/17 16:02, Kreuser, Peter wrote:
>>> Hi all,
>>>
>>> Sorry for the long text. I hope somebody can help me track down the problem 
>>> I'm facing with Tomcat (8.5.15), tcnative (1.2.12), openssl (1.1.0e) and 
>>> HTTP/2. JVM is zulu-8.21.0.1 (1.8.0_131-b11)
>>
>> No need to apologise. There was enough information in this report for me
>> to be 95% sure of what was going on before I tested things locally.
>>
>> 
>>
>>> Would be nice if somebody here could tell me if that is a bug or if I have 
>>> some misconfiguration.
>>
>> It is a bug.
>>
>> The short explanation is that with NIO2, the style of the API (async
>> read/write with CompletionHandlers) means that a TLS connection can get
>> closed down (by a CompletionHandler) before the access log entry is
>> written. This leads to passing a NULL reference to some native code
>> which - unsurprisingly - falls over (Tomcat is meant to make sure it
>> doesn't pass NULL references).
>>
>> There is an easy fix but the side-effect is that sometimes the cipher
>> suite name won't appear in the access log. Depending on timing on your
>> system that could be very frequent to almost never. I'd roughly expect
>> it to happen as frequently as the crashes.
>>
>> The harder fix is to note that we want the info and to ensure we cache
>> it before the TLS connection is closed down. In theory, we could do this
>> in the access log but it means parsing the request attribute config.
>> Performance wise, there will be an impact on users since the lookup to
>> populate the cache will occur during request processing rather than
>> afterwards. However, overall throughput should be unaffected.
>>
>> An alternative fix is for the application to trigger the caching of the
>> TLS info by requesting one of the TLD attributes.
>>
>> Switching to NIO should also fix this. Note, I would not expect NIO and
>> NIO2 to be much different performance wise.
>>
>> Would the easy fix be sufficient?
>>
>> Mark
> 
> For a start the easy fix would be sufficient. Apparently this is only a real 
> problem when I call the site via curl, as it does not happen in the various 
> browsers (at least not on every call).
> 
> We should at least make users aware that certain information can be missing 
> in the accesslog and the cause of it (in the AccessLogValve documentation?). 
> And are there any other implications of the asynchronicity? I guess the 
> behavior of NIO2 and HTTP/2 processing is not obvious?
> 
> Your alternative fix would be to copy the attributes during request 
> processing (in a filter) and then log them from the filter request attributes 
> instead of the predefined ssl attributes? Correct?
> 
> Thank you for your support and the bug fix ;-)! Have you filed the bug 
> internally or should I?

I need to look into this some more first. Remy's comments suggest that
my first analysis might have been wrong.

Mark

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

REST issue

2017-06-13 Thread Carl K. 

Some foundation facts:

Development environment using NetBeans 8.0.2, Tomcat 8.0.32, Java
jdk1.8.0_121 and Postman.

The code:

I have a simple hello world servlet for testing (in production, the
service will serve as an endpoint for information from another
organization):

package com.tsr.webservices;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.ws.rs.Consumes;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.json.JSONObject;

/**
  *
  * @author Carl
  */
@WebService(serviceName = "helloWorld")
@Path("/helloWorld")
public class AnoviaWebService {

/**
  * Retrieves representation of an instance of helloWorld.HelloWorld
  * @return an instance of java.lang.String
  */
 @GET
 @Produces("text/html")
 public String getHtml() {
 return "Hello, World!!";
 }
}

The web.xml contains these fragments:

...

 
 AnoviaWebService
org.glassfish.jersey.servlet.ServletContainer
 
jersey.config.server.provider.packages
com.tsr.webservice
 
 1
 

...

 
 AnoviaWebService
 /helloWorld/*
 

...

Tomcat starts properly with no errors.  Using Postman with either

http://192.168.0.117:8080/prod2test/helloWorld/getHtml

or

http://192.168.0.117:8080/prod2test/helloWorld

the first request after a rebuild/redeploy (we use a request filter and
I can see the request hitting the filter) returns a 200 OK but the jsp
that is displayed is the jsp that is displayed when the request failed
to pass the filter requirements.  Subsequent requests return a 404, not
found error and I can see the request never hits the filter after that
first request.

Additional notes.

1.  I am attempting to add this service to an existing application that
is quite large because, at some time in the not too distant future, the
entire application will be changed to run as a sevice so the client and
server sides can be decoupled.

2.  I have successfully created/deployed/run a REST service using the
NetBeans templates but it has no web.xml and uses the
'ApplicationConfig' process to expose the service.

If anyone has any ideas, I would certainly appreciate them.

Thanks,

Carl



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

AW: JVM Crash in tcnative due to concurrency/timing in HTTP/2

2017-06-13 Thread Kreuser, Peter 
Mark,

> On 09/06/17 16:02, Kreuser, Peter wrote:
> > Hi all,
> > 
> > Sorry for the long text. I hope somebody can help me track down the problem 
> > I'm facing with Tomcat (8.5.15), tcnative (1.2.12), openssl (1.1.0e) and 
> > HTTP/2. JVM is zulu-8.21.0.1 (1.8.0_131-b11)
> 
> No need to apologise. There was enough information in this report for me
> to be 95% sure of what was going on before I tested things locally.
> 
> 
> 
> > Would be nice if somebody here could tell me if that is a bug or if I have 
> > some misconfiguration.
> 
> It is a bug.
> 
> The short explanation is that with NIO2, the style of the API (async
> read/write with CompletionHandlers) means that a TLS connection can get
> closed down (by a CompletionHandler) before the access log entry is
> written. This leads to passing a NULL reference to some native code
> which - unsurprisingly - falls over (Tomcat is meant to make sure it
> doesn't pass NULL references).
> 
> There is an easy fix but the side-effect is that sometimes the cipher
> suite name won't appear in the access log. Depending on timing on your
> system that could be very frequent to almost never. I'd roughly expect
> it to happen as frequently as the crashes.
> 
> The harder fix is to note that we want the info and to ensure we cache
> it before the TLS connection is closed down. In theory, we could do this
> in the access log but it means parsing the request attribute config.
> Performance wise, there will be an impact on users since the lookup to
> populate the cache will occur during request processing rather than
> afterwards. However, overall throughput should be unaffected.
> 
> An alternative fix is for the application to trigger the caching of the
> TLS info by requesting one of the TLD attributes.
> 
> Switching to NIO should also fix this. Note, I would not expect NIO and
> NIO2 to be much different performance wise.
> 
> Would the easy fix be sufficient?
> 
> Mark

For a start the easy fix would be sufficient. Apparently this is only a real 
problem when I call the site via curl, as it does not happen in the various 
browsers (at least not on every call).

We should at least make users aware that certain information can be missing in 
the accesslog and the cause of it (in the AccessLogValve documentation?). And 
are there any other implications of the asynchronicity? I guess the behavior of 
NIO2 and HTTP/2 processing is not obvious?

Your alternative fix would be to copy the attributes during request processing 
(in a filter) and then log them from the filter request attributes instead of 
the predefined ssl attributes? Correct?

Thank you for your support and the bug fix ;-)! Have you filed the bug 
internally or should I?

Best regards

Peter 


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