release plan for tomcat 7.x for java9

[Mukarram Baig]

hello good folks!

I see that the endorsed directory related problem in tomcat 7.x for running
in java 9 has been fixed by the patch by rjung in
https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4


Do we know the approximate date by when we can expect a new release for 7.x
series that has this change?

Thanks for the awesome work guys!

Re: TLD scanning performance question

[Ray Holme]

And haveged works GREAT! Thanks Markus.
 

On Wednesday, October 25, 2017 10:53 AM, "i...@flyingfischer.ch" 
 wrote:
 

 
>
> Yes, it's the SecureRandom initialization that is killing you. Being a
> virtual server, it likely has no direct source of true randomness so
> it needs to pull from whatever the hypervisor is willing to provide.
>
> You'll need to ask your virtualization vendor for how to get access to
> more entropy, or switch to a less-secure random source (e.g.
> /dev/urandom on *NIX-like systems).
>
Install haveged and your boot up problems will be gone.

Markus


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


   

Re: TLD scanning performance question

[i...@flyingfischer.ch]

>
> Yes, it's the SecureRandom initialization that is killing you. Being a
> virtual server, it likely has no direct source of true randomness so
> it needs to pull from whatever the hypervisor is willing to provide.
>
> You'll need to ask your virtualization vendor for how to get access to
> more entropy, or switch to a less-secure random source (e.g.
> /dev/urandom on *NIX-like systems).
>
Install haveged and your boot up problems will be gone.

Markus


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

Re: TLD scanning performance question

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ray,

On 10/25/17 9:08 AM, Ray Holme wrote:
> I asked this question before (differently) and got some answers but
> now I think I understand what is really happening. I just want to
> confirm that I have finally understood what is happening. Given two
> Linux boxes running the same application, one is much slower
> starting (think that  "slower" machine is actually a much faster
> box) Here are some excerpts from the catalina.out log and my
> guesses as to what is happening.If someone knows why this is
> happening for sure, I would really appreciate knowing. - Both
> Linux machines run 8.5.13 Tomcat
> 
> log here - fedora 26 running real (not virtual) Oct 25, 2017
> 8:38:20 AM org.apache.jasper.servlet.TldScanner scanJars INFO: At
> least one JAR was scanned for TLDs yet contained no TLDs.  
> application @ 10/25/2017 8:38:20 Thread:15 SecurityFilter.init :
> 
> log server - Ubuntu running virtual (suspect machine much faster) 
> 25-Oct-2017 08:43:34.283 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars INFO: At least one
> JAR was scanned for TLDs yet contained no TLDs. .. 25-Oct-2017
> 08:45:00.151 INFO [localhost-startStop-1]
> org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom
> Creation of SecureRandom instance for session ID generation using
> [SHA1PRNG] took [85,739] milliseconds. application @ 10/25/2017
> 8:45:00 Thread:15 SecurityFilter.init :
> 
> 
> Both boxes have same list for jar scan skipping - includes all
> application jars used (had all tomcat jars already).Note that my
> machine use NO time to get on with it, but 1.5 minutes is used for
> the server.
> 
> I had an error in the scan skip lines and the time above was 10.5
> minutes till I fixed it so I know CATALINA_HOME is right. (left off
> a comma in middle of list, so it scanned a lot of jars - :=[ ).
> 
> I suspect the performance problem has nothing to do with jar
> scanning but has to do with the real (and virtual) server running
> with https not http for secure login (my development machine behind
> firewall with no external access) - perhaps the SecureRandom is the
> thing that is making this slow.

Yes, it's the SecureRandom initialization that is killing you. Being a
virtual server, it likely has no direct source of true randomness so
it needs to pull from whatever the hypervisor is willing to provide.

You'll need to ask your virtualization vendor for how to get access to
more entropy, or switch to a less-secure random source (e.g.
/dev/urandom on *NIX-like systems).

I'm not sure if these is consensus amongst security-minded individuals
as to whether or not using /dev/urandom is okay to do. If you are
generating long-lived key material (e.g. RSA, ssh, etc. keys) then I
think the answer is a definitely DO NOT USE. But for things like
session ids (which is the application in this case), IMO it's
reasonable to use this less-secure source of entropy.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnwj3QACgkQHPApP6U8
pFiv3xAAx/rxCxxwupWCbBqb21w6sby83EZtz0JkmCKaZYESnQ1mAHWmMbHWjJfN
EdH5dURsjPMP4lzrXNJTXUZYJW23ieWOMLycKeyXCzpFiqXBJ2nnremxOKKwhbBn
Xm/6U9CCtF2Ioextsqipk0WkuPWDnmyUkNOns/MVTBuy3A94RgTuIJiC0TRjMTsd
c6/9VuzSi0yBMf/xdpBZ47JmTM2ybojzBfSWHObynKjl+CDB9jx7GjXMxr2tIZ5d
D7kFTopD4QT9O12AbRX1lujfQMHCd1142GVfHrzSajCA31+ap0PAhPVTMWxFBhrC
F+Y/nnWoGR9yScMsbf+oVYLVFNeIdOmBVYaNJSF9d5YTaMdUc/0v4TDEa8Da6hE1
s42CpCHIUojtkzrMLFmex+MdumsJwISF8NbvPgrzpjY3phvTR/Xe4+XlUgvkFse/
i9fvf/9fH7ARMul5g/XVD1vVH8N3Sg/YjJ/8gqno85hK/Im6mQbaX9z6sFRhhcYd
+jt1+n5n661KhKGlkIzDxCbYxvU17c940umdiqLxWUUQp8oq9Ra7dvr+hVdpU1lC
ZWGYYwuufcemZ66KLoafgswlD9dIxrrx1cehFwcFbLixW2hmAOfG2zgZ+Mvmrcj9
NlYkeDhijbnK8P/8ixThfHNtGmtoDpTPnGJZ5kPvLrP90E2EpUI=
=YSRO
-END PGP SIGNATURE-

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

Re: The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Karen,

On 10/20/17 1:11 AM, Karen Goh wrote:
> Today I receive an error message that I have never come across.
> 
> "Https status 404 - not found " "The origin server did not find a
> current representation for the target resource or is not willing to
> disclose that one exists."
> 
> I have googled but there is no solution that can help me.
> 
> So far, I have delete the server and add a new one but it is not
> helpful.
> 
> So far, my context.xml is correct so rightfully, the
> tutorRegister.jsp page should appear.
> 
> Here's my context.xml and I am running on Eclipse NEON 3 with Maven
> and it is a dynamic web project.
> 
> http://xmlns.jcp.org/xml/ns/javaee; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; version="3.1"> 
> Hi5S  
> tutorRegister.jsp 
>   
> mydb 
> jdbc/hi5 
> javax.sql.DataSource 
> Container  

That's a web.xml not a context.xml. Where did you put that file on the
disk (full path please)? Also, where can tutorRegister.jsp be found?
What URL did you use to try to load this resource?

What version of Tomcat are you using?

Are you using a reverse-proxy between the client (browser) and Tomcat?
That message "The origin server..." does not sound familiar, so I
think it's coming from another component.

- -chris

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnwjdEACgkQHPApP6U8
pFj7nhAAm8CHV6omQhCVnLIQj+UBFUagOXdLPp/abS5UEm8WFFpM/4UDdIDJh8bn
RsInoynOz6Q/ln/5lh7lv8DB/x6FXOQDYcCs5iXVYPONN+HovKwnaMHwc3RBCz8j
FXTQph+7GGaFehn0BM9pz+difwt9beWar2IigOEluqiP1/CZDhE2Uu7GHnA7KG/Z
AxiKeRkUm4nqm93U6gz7JRulkwqAwLy/vhA2JFedaQdqBYu3RttvtlzE1RJpMOBP
QKtAllPsrk9H9dV+xQTx0gxjciHmCPgQ5nBaMaYLVnN4JoWnIIR+2a4EUYY4gGoO
+c+jRyrWA6B0BYl5Y3afT284rHs499luAHkDWYhUuwy0hTVVIOOqF23LXMRTflBh
9Cdspy+9cDLNTUni2JqqYq2B+IuyEZhR9weNrpbltEw0AYK68wEIp73/WejwtsuB
udJInlepk20vpavg6zNnOwpNKbOkz/I4uSCAXZ/7/WzKJY36nHbpd6eCA6KxMx51
bs+NAanb/R+HxMnTsPISYNKSaTdxbXJQzdbqwXC0AqvJ7EksAzRpMimNUfYhf6ZM
CpK4XvTnra6jPwTs3qH+557FCho22d5vjkbQfmR01sNo4Z16YJvUgIbRDzZDp+DC
+RsVxkRRnCq0Cozud1lddPJbqI2Ntopb/h8N16gWFttIZHA3YX0=
=uMFs
-END PGP SIGNATURE-

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

TLD scanning performance question

[Ray Holme]

I asked this question before (differently) and got some answers but now I think 
I understand what is really happening.
I just want to confirm that I have finally understood what is happening.
Given two Linux boxes running the same application, one is much slower starting 
(think that  "slower" machine is actually a much faster box)
Here are some excerpts from the catalina.out log and my guesses as to what is 
happening.If someone knows why this is happening for sure, I would really 
appreciate knowing.
-
Both Linux machines run 8.5.13 Tomcat

log here - fedora 26 running real (not virtual)
Oct 25, 2017 8:38:20 AM org.apache.jasper.servlet.TldScanner scanJars
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. 
application @ 10/25/2017 8:38:20 Thread:15 SecurityFilter.init : 

log server - Ubuntu running virtual (suspect machine much faster)
25-Oct-2017 08:43:34.283 INFO [localhost-startStop-1] 
org.apache.jasper.servlet.TldScanner.scanJars
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. ..
25-Oct-2017 08:45:00.151 INFO [localhost-startStop-1] 
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of 
SecureRandom instance for session ID generation using [SHA1PRNG] took [85,739] 
milliseconds.
application @ 10/25/2017 8:45:00 Thread:15 SecurityFilter.init :


Both boxes have same list for jar scan skipping - includes all application jars 
used
  (had all tomcat jars already).Note that my machine use NO time to get on with 
it, but 1.5 minutes is used for the server.

I had an error in the scan skip lines and the time above was 10.5 minutes till 
I fixed it so I know CATALINA_HOME is right.
  (left off a comma in middle of list, so it scanned a lot of jars - :=[ ).

I suspect the performance problem has nothing to do with jar scanning but has 
to do with the real (and virtual)
server running with https not http for secure login (my development machine 
behind firewall with no external access)
- perhaps the SecureRandom is the thing that is making this slow.

Re: Tomcat 8.0.33 Crashed

[Atanu Pal]

Still can you help me explain little more about the root cause?

That will help me to explain it to customer and setup a test
environment for future.
Thanks and Regards
Atanu Pal
E2Infosystems - Chennai


On Wed, Oct 25, 2017 at 5:36 PM, Atanu Pal  wrote:
> Thanks Mark, I was inclining to the same, I will try 8.0.47 first
> before jumping to 8.5.x, will let you know what happens.
> Thanks and Regards
> Atanu Pal
> E2Infosystems - Chennai
>
>
> On Wed, Oct 25, 2017 at 5:30 PM, Mark Thomas  wrote:
>> On 25/10/17 11:43, Atanu Pal wrote:
>>> Hi,
>>>
>>> We have application deployed on tomcat & its working good for most of
>>> the customer, but recently we installed it for two customers on a
>>> virtual machine & it looks like tomcat is crashing after few days of
>>> successful run.
>>>
>>> Machine Details:
>>> - It is a Virtual Machine
>>> - Windows Server 2012 R2
>>> - 64-bit, 8GB RAM
>>> - Intel Xeon E5-2665 dual processor @2.4GHz
>>>
>>> Both the server crashed with almost exact same crash log.
>>>
>>> As per my google research & if I am reading this crash log right, then
>>> this issue happened due to APR Module while doing polling.
>>>
>>> We are trying to find root cause of this problem, these are my top suspect:
>>> 1. Its a VM machine thing.
>>> 2. Bug in tomcat APR module.
>>
>> 2 is the more likely option.
>>
>> There have been a number of APR/native bugs that are very timing
>> dependent. It is quite possible that the move the a VM altering the
>> timing slightly and did so in such a way that you hit a APR/native bug.
>>
>> I'd recommend updating to the latest 8.0.x release. Better still, the
>> latest 8.5.x. (8.5.x should be a drop in replacement for 8.0.x for
>> nearly all users). Also make sure you are using the latest Tomcat native
>> 1.2.x library.
>>
>> Mark
>>
>>
>>>
>>> Let me know how should we fix this issue & if its already fixed please
>>> guide to fixed version.
>>>
>>> I have posted same question on stackoverflow :
>>> https://stackoverflow.com/questions/46925905/tomcat-8-0-33-crashed-due-to-apr-in-a-virtual-machine
>>>
>>> Copying 1 Crash log below, I have one more very similar to this & two
>>> memory dump. let me know if you need any of those to help me out here.
>>> Memory dump is quite big so I can upload it on Google-drive & share it
>>> with you.
>>>
>>> Crash Log 1:
>>> 
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x23a56eb6, pid=3084, 
>>> tid=5852
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build 
>>> 1.8.0_77-b03)
>>> # Java VM: Java HotSpot(TM) Server VM (25.77-b03 mixed mode windows-x86 )
>>> # Problematic frame:
>>> # C  [tcnative-1.dll+0x6eb6]
>>> #
>>> # Core dump written. Default location: <>
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> #   http://bugreport.java.com/bugreport/crash.jsp
>>> # The crash happened outside the Java Virtual Machine in native code.
>>> # See problematic frame for where to report the bug.
>>> #
>>>
>>> ---  T H R E A D  ---
>>>
>>> Current thread (0x24c7ac00):  JavaThread "http-apr-8082-Poller" daemon
>>> [_thread_in_native, id=5852, stack(0x2b06,0x2b0d)]
>>>
>>> siginfo: ExceptionCode=0xc005, reading address 0x3941f0b4
>>>
>>> Registers:
>>> EAX=0x3941f098, EBX=0x23be18e0, ECX=0x23be27b0, EDX=0x
>>> ESP=0x2b0cfac4, EBP=0x2b0cfae8, ESI=0x3941f098, EDI=0x
>>> EIP=0x23a56eb6, EFLAGS=0x00010202
>>>
>>> Top of Stack: (sp=0x2b0cfac4)
>>> 0x2b0cfac4:   24c7ac00 2b0cfb18  00fa
>>> 0x2b0cfad4:    838e735e 00055c23 23bdc7a8
>>> 0x2b0cfae4:   00db 2b0cfb28 014aad14 24c7ad40
>>> 0x2b0cfaf4:   2b0cfb18 23be18e0  00fa
>>> 0x2b0cfb04:    2b0cfb10 0001 11d94a90
>>> 0x2b0cfb14:   2710 11e05348 0400 f8ce8c91
>>> 0x2b0cfb24:   01d34b41 00fa 021c140c 23be18e0
>>> 0x2b0cfb34:    00fa  11d8e430
>>>
>>> Instructions: (pc=0x23a56eb6)
>>> 0x23a56e96:   41 0a 8b 71 10 8b 4b 10 99 89 04 0f 89 54 0f 04
>>> 0x23a56ea6:   8b 4b 10 8b c6 99 89 44 0f 08 89 54 0f 0c 74 59
>>> 0x23a56eb6:   83 7e 1c 00 74 5f 8b 45 f8 8b 4b 0c 50 51 e8 37
>>> 0x23a56ec6:   53 01 00 8b 56 1c 8b 02 8b 4e 1c 8b 51 04 89 02
>>>
>>>
>>> Register to memory mapping:
>>>
>>> EAX=0x3941f098 is an unknown value
>>> EBX=0x23be18e0 is an unknown value
>>> ECX=0x23be27b0 is an unknown value
>>> EDX=0x is an unknown value
>>> ESP=0x2b0cfac4 is pointing into the stack for thread: 0x24c7ac00
>>> EBP=0x2b0cfae8 is pointing into the stack for thread: 0x24c7ac00
>>> ESI=0x3941f098 is an unknown value
>>> EDI=0x is an unknown value
>>>
>>>
>>> Stack: [0x2b06,0x2b0d],  sp=0x2b0cfac4,  free space=446k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>>> code)
>>> C  

Re: Tomcat 8.0.33 Crashed

[Atanu Pal]

Thanks Mark, I was inclining to the same, I will try 8.0.47 first
before jumping to 8.5.x, will let you know what happens.
Thanks and Regards
Atanu Pal
E2Infosystems - Chennai


On Wed, Oct 25, 2017 at 5:30 PM, Mark Thomas  wrote:
> On 25/10/17 11:43, Atanu Pal wrote:
>> Hi,
>>
>> We have application deployed on tomcat & its working good for most of
>> the customer, but recently we installed it for two customers on a
>> virtual machine & it looks like tomcat is crashing after few days of
>> successful run.
>>
>> Machine Details:
>> - It is a Virtual Machine
>> - Windows Server 2012 R2
>> - 64-bit, 8GB RAM
>> - Intel Xeon E5-2665 dual processor @2.4GHz
>>
>> Both the server crashed with almost exact same crash log.
>>
>> As per my google research & if I am reading this crash log right, then
>> this issue happened due to APR Module while doing polling.
>>
>> We are trying to find root cause of this problem, these are my top suspect:
>> 1. Its a VM machine thing.
>> 2. Bug in tomcat APR module.
>
> 2 is the more likely option.
>
> There have been a number of APR/native bugs that are very timing
> dependent. It is quite possible that the move the a VM altering the
> timing slightly and did so in such a way that you hit a APR/native bug.
>
> I'd recommend updating to the latest 8.0.x release. Better still, the
> latest 8.5.x. (8.5.x should be a drop in replacement for 8.0.x for
> nearly all users). Also make sure you are using the latest Tomcat native
> 1.2.x library.
>
> Mark
>
>
>>
>> Let me know how should we fix this issue & if its already fixed please
>> guide to fixed version.
>>
>> I have posted same question on stackoverflow :
>> https://stackoverflow.com/questions/46925905/tomcat-8-0-33-crashed-due-to-apr-in-a-virtual-machine
>>
>> Copying 1 Crash log below, I have one more very similar to this & two
>> memory dump. let me know if you need any of those to help me out here.
>> Memory dump is quite big so I can upload it on Google-drive & share it
>> with you.
>>
>> Crash Log 1:
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x23a56eb6, pid=3084, 
>> tid=5852
>> #
>> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build 
>> 1.8.0_77-b03)
>> # Java VM: Java HotSpot(TM) Server VM (25.77-b03 mixed mode windows-x86 )
>> # Problematic frame:
>> # C  [tcnative-1.dll+0x6eb6]
>> #
>> # Core dump written. Default location: <>
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.java.com/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>>
>> ---  T H R E A D  ---
>>
>> Current thread (0x24c7ac00):  JavaThread "http-apr-8082-Poller" daemon
>> [_thread_in_native, id=5852, stack(0x2b06,0x2b0d)]
>>
>> siginfo: ExceptionCode=0xc005, reading address 0x3941f0b4
>>
>> Registers:
>> EAX=0x3941f098, EBX=0x23be18e0, ECX=0x23be27b0, EDX=0x
>> ESP=0x2b0cfac4, EBP=0x2b0cfae8, ESI=0x3941f098, EDI=0x
>> EIP=0x23a56eb6, EFLAGS=0x00010202
>>
>> Top of Stack: (sp=0x2b0cfac4)
>> 0x2b0cfac4:   24c7ac00 2b0cfb18  00fa
>> 0x2b0cfad4:    838e735e 00055c23 23bdc7a8
>> 0x2b0cfae4:   00db 2b0cfb28 014aad14 24c7ad40
>> 0x2b0cfaf4:   2b0cfb18 23be18e0  00fa
>> 0x2b0cfb04:    2b0cfb10 0001 11d94a90
>> 0x2b0cfb14:   2710 11e05348 0400 f8ce8c91
>> 0x2b0cfb24:   01d34b41 00fa 021c140c 23be18e0
>> 0x2b0cfb34:    00fa  11d8e430
>>
>> Instructions: (pc=0x23a56eb6)
>> 0x23a56e96:   41 0a 8b 71 10 8b 4b 10 99 89 04 0f 89 54 0f 04
>> 0x23a56ea6:   8b 4b 10 8b c6 99 89 44 0f 08 89 54 0f 0c 74 59
>> 0x23a56eb6:   83 7e 1c 00 74 5f 8b 45 f8 8b 4b 0c 50 51 e8 37
>> 0x23a56ec6:   53 01 00 8b 56 1c 8b 02 8b 4e 1c 8b 51 04 89 02
>>
>>
>> Register to memory mapping:
>>
>> EAX=0x3941f098 is an unknown value
>> EBX=0x23be18e0 is an unknown value
>> ECX=0x23be27b0 is an unknown value
>> EDX=0x is an unknown value
>> ESP=0x2b0cfac4 is pointing into the stack for thread: 0x24c7ac00
>> EBP=0x2b0cfae8 is pointing into the stack for thread: 0x24c7ac00
>> ESI=0x3941f098 is an unknown value
>> EDI=0x is an unknown value
>>
>>
>> Stack: [0x2b06,0x2b0d],  sp=0x2b0cfac4,  free space=446k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> C  [tcnative-1.dll+0x6eb6]
>> J 6544  org.apache.tomcat.jni.Poll.poll(JJ[JZ)I (0 bytes) @ 0x014aad14
>> [0x014aac60+0xb4]
>> J 8272% C2 org.apache.tomcat.util.net.AprEndpoint$Poller.run()V (2267
>> bytes) @ 0x021c140c [0x021c11c0+0x24c]
>> j  java.lang.Thread.run()V+11
>> v  ~StubRoutines::call_stub
>> V  [jvm.dll+0x16db95]
>> V  [jvm.dll+0x24047e]
>> V  [jvm.dll+0x16dc2e]
>> V  [jvm.dll+0x16ddb6]
>> V  [jvm.dll+0x16de27]
>> V  

Re: Tomcat 8.0.33 Crashed

[Mark Thomas]

On 25/10/17 11:43, Atanu Pal wrote:
> Hi,
> 
> We have application deployed on tomcat & its working good for most of
> the customer, but recently we installed it for two customers on a
> virtual machine & it looks like tomcat is crashing after few days of
> successful run.
> 
> Machine Details:
> - It is a Virtual Machine
> - Windows Server 2012 R2
> - 64-bit, 8GB RAM
> - Intel Xeon E5-2665 dual processor @2.4GHz
> 
> Both the server crashed with almost exact same crash log.
> 
> As per my google research & if I am reading this crash log right, then
> this issue happened due to APR Module while doing polling.
> 
> We are trying to find root cause of this problem, these are my top suspect:
> 1. Its a VM machine thing.
> 2. Bug in tomcat APR module.

2 is the more likely option.

There have been a number of APR/native bugs that are very timing
dependent. It is quite possible that the move the a VM altering the
timing slightly and did so in such a way that you hit a APR/native bug.

I'd recommend updating to the latest 8.0.x release. Better still, the
latest 8.5.x. (8.5.x should be a drop in replacement for 8.0.x for
nearly all users). Also make sure you are using the latest Tomcat native
1.2.x library.

Mark


> 
> Let me know how should we fix this issue & if its already fixed please
> guide to fixed version.
> 
> I have posted same question on stackoverflow :
> https://stackoverflow.com/questions/46925905/tomcat-8-0-33-crashed-due-to-apr-in-a-virtual-machine
> 
> Copying 1 Crash log below, I have one more very similar to this & two
> memory dump. let me know if you need any of those to help me out here.
> Memory dump is quite big so I can upload it on Google-drive & share it
> with you.
> 
> Crash Log 1:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x23a56eb6, pid=3084, 
> tid=5852
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build 
> 1.8.0_77-b03)
> # Java VM: Java HotSpot(TM) Server VM (25.77-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C  [tcnative-1.dll+0x6eb6]
> #
> # Core dump written. Default location: <>
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> 
> ---  T H R E A D  ---
> 
> Current thread (0x24c7ac00):  JavaThread "http-apr-8082-Poller" daemon
> [_thread_in_native, id=5852, stack(0x2b06,0x2b0d)]
> 
> siginfo: ExceptionCode=0xc005, reading address 0x3941f0b4
> 
> Registers:
> EAX=0x3941f098, EBX=0x23be18e0, ECX=0x23be27b0, EDX=0x
> ESP=0x2b0cfac4, EBP=0x2b0cfae8, ESI=0x3941f098, EDI=0x
> EIP=0x23a56eb6, EFLAGS=0x00010202
> 
> Top of Stack: (sp=0x2b0cfac4)
> 0x2b0cfac4:   24c7ac00 2b0cfb18  00fa
> 0x2b0cfad4:    838e735e 00055c23 23bdc7a8
> 0x2b0cfae4:   00db 2b0cfb28 014aad14 24c7ad40
> 0x2b0cfaf4:   2b0cfb18 23be18e0  00fa
> 0x2b0cfb04:    2b0cfb10 0001 11d94a90
> 0x2b0cfb14:   2710 11e05348 0400 f8ce8c91
> 0x2b0cfb24:   01d34b41 00fa 021c140c 23be18e0
> 0x2b0cfb34:    00fa  11d8e430
> 
> Instructions: (pc=0x23a56eb6)
> 0x23a56e96:   41 0a 8b 71 10 8b 4b 10 99 89 04 0f 89 54 0f 04
> 0x23a56ea6:   8b 4b 10 8b c6 99 89 44 0f 08 89 54 0f 0c 74 59
> 0x23a56eb6:   83 7e 1c 00 74 5f 8b 45 f8 8b 4b 0c 50 51 e8 37
> 0x23a56ec6:   53 01 00 8b 56 1c 8b 02 8b 4e 1c 8b 51 04 89 02
> 
> 
> Register to memory mapping:
> 
> EAX=0x3941f098 is an unknown value
> EBX=0x23be18e0 is an unknown value
> ECX=0x23be27b0 is an unknown value
> EDX=0x is an unknown value
> ESP=0x2b0cfac4 is pointing into the stack for thread: 0x24c7ac00
> EBP=0x2b0cfae8 is pointing into the stack for thread: 0x24c7ac00
> ESI=0x3941f098 is an unknown value
> EDI=0x is an unknown value
> 
> 
> Stack: [0x2b06,0x2b0d],  sp=0x2b0cfac4,  free space=446k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> C  [tcnative-1.dll+0x6eb6]
> J 6544  org.apache.tomcat.jni.Poll.poll(JJ[JZ)I (0 bytes) @ 0x014aad14
> [0x014aac60+0xb4]
> J 8272% C2 org.apache.tomcat.util.net.AprEndpoint$Poller.run()V (2267
> bytes) @ 0x021c140c [0x021c11c0+0x24c]
> j  java.lang.Thread.run()V+11
> v  ~StubRoutines::call_stub
> V  [jvm.dll+0x16db95]
> V  [jvm.dll+0x24047e]
> V  [jvm.dll+0x16dc2e]
> V  [jvm.dll+0x16ddb6]
> V  [jvm.dll+0x16de27]
> V  [jvm.dll+0x10a73f]
> V  [jvm.dll+0x192a7c]
> V  [jvm.dll+0x192b6a]
> V  [jvm.dll+0x1d7356]
> C  [MSVCR100.dll+0x5c556]
> C  [MSVCR100.dll+0x5c600]
> C  [KERNEL32.DLL+0x17c04]
> C  [ntdll.dll+0x5ad2f]
> C  [ntdll.dll+0x5acfa]
> C  0x
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> J 6544  org.apache.tomcat.jni.Poll.poll(JJ[JZ)I (0 bytes) @ 

Tomcat 8.0.33 Crashed

[Atanu Pal]

Hi,

We have application deployed on tomcat & its working good for most of
the customer, but recently we installed it for two customers on a
virtual machine & it looks like tomcat is crashing after few days of
successful run.

Machine Details:
- It is a Virtual Machine
- Windows Server 2012 R2
- 64-bit, 8GB RAM
- Intel Xeon E5-2665 dual processor @2.4GHz

Both the server crashed with almost exact same crash log.

As per my google research & if I am reading this crash log right, then
this issue happened due to APR Module while doing polling.

We are trying to find root cause of this problem, these are my top suspect:
1. Its a VM machine thing.
2. Bug in tomcat APR module.

Let me know how should we fix this issue & if its already fixed please
guide to fixed version.

I have posted same question on stackoverflow :
https://stackoverflow.com/questions/46925905/tomcat-8-0-33-crashed-due-to-apr-in-a-virtual-machine

Copying 1 Crash log below, I have one more very similar to this & two
memory dump. let me know if you need any of those to help me out here.
Memory dump is quite big so I can upload it on Google-drive & share it
with you.

Crash Log 1:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x23a56eb6, pid=3084, tid=5852
#
# JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build 1.8.0_77-b03)
# Java VM: Java HotSpot(TM) Server VM (25.77-b03 mixed mode windows-x86 )
# Problematic frame:
# C  [tcnative-1.dll+0x6eb6]
#
# Core dump written. Default location: <>
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x24c7ac00):  JavaThread "http-apr-8082-Poller" daemon
[_thread_in_native, id=5852, stack(0x2b06,0x2b0d)]

siginfo: ExceptionCode=0xc005, reading address 0x3941f0b4

Registers:
EAX=0x3941f098, EBX=0x23be18e0, ECX=0x23be27b0, EDX=0x
ESP=0x2b0cfac4, EBP=0x2b0cfae8, ESI=0x3941f098, EDI=0x
EIP=0x23a56eb6, EFLAGS=0x00010202

Top of Stack: (sp=0x2b0cfac4)
0x2b0cfac4:   24c7ac00 2b0cfb18  00fa
0x2b0cfad4:    838e735e 00055c23 23bdc7a8
0x2b0cfae4:   00db 2b0cfb28 014aad14 24c7ad40
0x2b0cfaf4:   2b0cfb18 23be18e0  00fa
0x2b0cfb04:    2b0cfb10 0001 11d94a90
0x2b0cfb14:   2710 11e05348 0400 f8ce8c91
0x2b0cfb24:   01d34b41 00fa 021c140c 23be18e0
0x2b0cfb34:    00fa  11d8e430

Instructions: (pc=0x23a56eb6)
0x23a56e96:   41 0a 8b 71 10 8b 4b 10 99 89 04 0f 89 54 0f 04
0x23a56ea6:   8b 4b 10 8b c6 99 89 44 0f 08 89 54 0f 0c 74 59
0x23a56eb6:   83 7e 1c 00 74 5f 8b 45 f8 8b 4b 0c 50 51 e8 37
0x23a56ec6:   53 01 00 8b 56 1c 8b 02 8b 4e 1c 8b 51 04 89 02


Register to memory mapping:

EAX=0x3941f098 is an unknown value
EBX=0x23be18e0 is an unknown value
ECX=0x23be27b0 is an unknown value
EDX=0x is an unknown value
ESP=0x2b0cfac4 is pointing into the stack for thread: 0x24c7ac00
EBP=0x2b0cfae8 is pointing into the stack for thread: 0x24c7ac00
ESI=0x3941f098 is an unknown value
EDI=0x is an unknown value


Stack: [0x2b06,0x2b0d],  sp=0x2b0cfac4,  free space=446k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [tcnative-1.dll+0x6eb6]
J 6544  org.apache.tomcat.jni.Poll.poll(JJ[JZ)I (0 bytes) @ 0x014aad14
[0x014aac60+0xb4]
J 8272% C2 org.apache.tomcat.util.net.AprEndpoint$Poller.run()V (2267
bytes) @ 0x021c140c [0x021c11c0+0x24c]
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [jvm.dll+0x16db95]
V  [jvm.dll+0x24047e]
V  [jvm.dll+0x16dc2e]
V  [jvm.dll+0x16ddb6]
V  [jvm.dll+0x16de27]
V  [jvm.dll+0x10a73f]
V  [jvm.dll+0x192a7c]
V  [jvm.dll+0x192b6a]
V  [jvm.dll+0x1d7356]
C  [MSVCR100.dll+0x5c556]
C  [MSVCR100.dll+0x5c600]
C  [KERNEL32.DLL+0x17c04]
C  [ntdll.dll+0x5ad2f]
C  [ntdll.dll+0x5acfa]
C  0x

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 6544  org.apache.tomcat.jni.Poll.poll(JJ[JZ)I (0 bytes) @ 0x014aacd0
[0x014aac60+0x70]
J 8272% C2 org.apache.tomcat.util.net.AprEndpoint$Poller.run()V (2267
bytes) @ 0x021c140c [0x021c11c0+0x24c]
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

---  P R O C E S S  ---

Java Threads: ( => current thread )
  0x2315c800 JavaThread "Thread-176703" daemon [_thread_blocked,
id=5448, stack(0x3d50,0x3d57)]
  0x2316 JavaThread "Keep-Alive-Timer" daemon [_thread_blocked,
id=5276, stack(0x3d45,0x3d4c)]
  0x2315fc00 JavaThread "http-apr-8082-exec-2223" daemon
[_thread_blocked, id=6724, stack(0x3d3a,0x3d41)]
  0x2315b400 JavaThread "http-apr-8082-exec-" daemon
[_thread_blocked, id=5016, stack(0x3d2f,0x3d36)]
  0x2315c000 JavaThread 

Re: Default response charset

[Lazar Kirchev]

Thanks a lot Mark!

On Wed, Oct 25, 2017 at 12:51 PM, Mark Thomas  wrote:

> On 25/10/17 10:23, Mark Thomas wrote:
> > On 24/10/17 07:36, Lazar Kirchev wrote:
> >> Hello,
> >>
> >> Change http://svn.apache.org/viewvc?view=revision=1801052
> tries,
> >> in case no charset is specified for the response, to determine a default
> >> one based on the content language if such is present. For en and fr
> >> languages the ISO-8859-1 charset is used as default.
> >
> > There is slightly more to it than that.
> >
> > If the application sets the "Content-Language" header then Tomcat
> > extracts the Locale from that header and calls setLocale().
> >
> > This behaviour is not required by the specification but is one of a
> > number of cases where Tomcat tries to map the explicit setting of HTTP
> > headers to Servlet API calls. "Content-Type" and "Content-Length" are
> > the others.
>
> Hmm. Looking at Tomcat 9 that code is no longer there. It isn't there in
> 8.0.x either. Digging in the svn history the "Content-Language" handling
> was removed (r1374824) shortly after it was added (r1374073). The commit
> message doesn't explain why.
>
> Time to check the mail archives...
>
> ... and here is the thread:
> http://tomcat.markmail.org/thread/qhnzq7v3dopgi7uz
>
> Having reviewed that thread, I don't see anything that has really
> changed since 2012. On that basis I'll remove "Content-Language"
> handling from 7.0.x to align it with the other versions.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Default response charset

[Mark Thomas]

On 25/10/17 10:23, Mark Thomas wrote:
> On 24/10/17 07:36, Lazar Kirchev wrote:
>> Hello,
>>
>> Change http://svn.apache.org/viewvc?view=revision=1801052 tries,
>> in case no charset is specified for the response, to determine a default
>> one based on the content language if such is present. For en and fr
>> languages the ISO-8859-1 charset is used as default.
> 
> There is slightly more to it than that.
> 
> If the application sets the "Content-Language" header then Tomcat
> extracts the Locale from that header and calls setLocale().
> 
> This behaviour is not required by the specification but is one of a
> number of cases where Tomcat tries to map the explicit setting of HTTP
> headers to Servlet API calls. "Content-Type" and "Content-Length" are
> the others.

Hmm. Looking at Tomcat 9 that code is no longer there. It isn't there in
8.0.x either. Digging in the svn history the "Content-Language" handling
was removed (r1374824) shortly after it was added (r1374073). The commit
message doesn't explain why.

Time to check the mail archives...

... and here is the thread:
http://tomcat.markmail.org/thread/qhnzq7v3dopgi7uz

Having reviewed that thread, I don't see anything that has really
changed since 2012. On that basis I'll remove "Content-Language"
handling from 7.0.x to align it with the other versions.

Mark

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

Re: Default response charset

[Mark Thomas]

On 24/10/17 07:36, Lazar Kirchev wrote:
> Hello,
> 
> Change http://svn.apache.org/viewvc?view=revision=1801052 tries,
> in case no charset is specified for the response, to determine a default
> one based on the content language if such is present. For en and fr
> languages the ISO-8859-1 charset is used as default.

There is slightly more to it than that.

If the application sets the "Content-Language" header then Tomcat
extracts the Locale from that header and calls setLocale().

This behaviour is not required by the specification but is one of a
number of cases where Tomcat tries to map the explicit setting of HTTP
headers to Servlet API calls. "Content-Type" and "Content-Length" are
the others.

The Servlet specification requires that a call to setLocale() also sets
the character encoding if one has not already been set via
setCharacterEncoding() or setContentType().

> However, this is done for all content types, not only for text media types.
> Is this intentional?

Yes. The Servlet specification requirement that a call to setLocale()
also sets the character encoding if one has not already been set is not
dependent on content type.

> For example, for some media types (particularly
> application/json) this could lead to incorrect representation of characters.

It is always better to explicitly set the content type and character set.

Mark

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

Re: At a loss!

[Mark Thomas]

On 24/10/17 12:23, Courtney Meade wrote:
> tomcat-connectors-1.2.42-windows-x86_64-iis.zip 

Good. That should be the correct version of the DLL since Windows 2012
is only available in 64 bit.

The error you are seeing is typically seen when there is a configuration
issue of some kind.

The Tomcat provided docs could really do with an update for how to
install and configure the DLL. Until we get that done, this might helP:

https://www.lisenet.com/2016/configure-iis-8-and-tomcat-connector-isapi-filter-on-windows-server-2012/

Mark


> 
> Courtney Meade
> Business Applications Analyst
> ITS - City of Cape Coral
> Internal Ext 3694
> Phone 239-242-3694
> (NOTE:  Florida has a very broad public records law, and under Florida law, 
> most written communications to or from city staff regarding city business to 
> include your e-mail address is considered public records and will be made 
> available to the public and the media upon request. If you do not want your 
> email message and or your e-mail address released in response to a public 
> records request, do not send electronic mail to this entity. Instead, contact 
> this office by phone or in writing.  Additionally, this communication is 
> intended only for the addressee.  If you are not the intended recipient, do 
> not copy, disclose, or distribute this message to anyone else.  If you have 
> received this communication in error, please contact the sender of the 
> message to inform him or her of the error and then delete this message.)
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Monday, October 23, 2017 5:11 PM
> To: Tomcat Users List 
> Subject: Re: At a loss!
> 
> On 23/10/17 12:28, Courtney Meade wrote:
>> Tomcat is 7.0.82
>>
>> http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/
>>
>> The above is the download for the isapi redirect file.
> 
> No, it isn't. The files are in a directory one level below that (named
> Windows) and there are two different zip files you could have down loaded. 
> Which one did you download?
> 
> I'm going to assume you downloaded the latest version, 1.2.42 unless you say 
> otherwise.
> 
> Mark
> 
> 
> 
>>
>> I had to follow the footprints instruction and the file was placed under the 
>> tomcat 7.0 directory in a folder called isapi. 
>>
>> Courtney Meade
>> Business Applications Analyst
>> ITS - City of Cape Coral
>> Internal Ext 3694
>> Phone 239-242-3694
>> (NOTE:  Florida has a very broad public records law, and under Florida 
>> law, most written communications to or from city staff regarding city 
>> business to include your e-mail address is considered public records 
>> and will be made available to the public and the media upon request. 
>> If you do not want your email message and or your e-mail address 
>> released in response to a public records request, do not send 
>> electronic mail to this entity. Instead, contact this office by phone 
>> or in writing.  Additionally, this communication is intended only for 
>> the addressee.  If you are not the intended recipient, do not copy, 
>> disclose, or distribute this message to anyone else.  If you have 
>> received this communication in error, please contact the sender of the 
>> message to inform him or her of the error and then delete this 
>> message.)
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Friday, October 20, 2017 3:29 PM
>> To: Tomcat Users List 
>> Subject: Re: At a loss!
>>
>> On 20/10/17 19:52, Courtney Meade wrote:
>>> Receiving the below Error when trying to Integrate Tomcat with IIS for 
>>> Footprints - any help or insight would be greatly appreciated!
>>>
>>> Tomcat Version - 7.0
>>
>> Not relevant at this point but "7.0" as a Tomcat version number is close to 
>> useless given it could be any one of 80 odd releases spread over more than 7 
>> years.
>>
>>> Server OS - Windows 2012 R2
>>
>> OK.
>>
>> Exactly which isapi_redirect.dll file did you install (version, 
>> architecture, download source) and how did you install it?
>>
>> Mark
>>
>>
>>>
>>>
>>> HTTP Error 500.0 - Internal Server Error Calling GetFilterVersion on 
>>> ISAPI filter "C:\Program Files\Apache Software Foundation\Tomcat 
>>> 7.0\isapi\isapi_redirect.dll" failed Most likely causes:
>>> * IIS received the request; however, an internal error occurred 
>>> during the processing of the request. The root cause of this error depends 
>>> on which module handles the request and what was happening in the worker 
>>> process when this error occurred.
>>> * IIS was not able to access the web.config file for the Web site 
>>> or application. This can occur if the NTFS permissions are set incorrectly.
>>> * IIS was not able to process configuration for the Web site or 
>>> application.
>>> * The authenticated user does not have permission to use this DLL.
>>> * The request is mapped to a managed