RE: GC allocation failure

[Sanka, Ambica]

Thank you. I will make initial and max heap to be same value.

Ambica Sanka
Sr J2EE IV Developer
office  703.661.7928

atpco.net
linkedIn  /  twitter @atpconews

45005 Aviation Drive
Dulles, VA 20166




-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, January 04, 2018 12:20 PM
To: users@tomcat.apache.org
Subject: Re: GC allocation failure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ambica,

On 1/4/18 11:17 AM, Sanka, Ambica wrote:
> I am seeing below highlighted errors in native_err logs in all my 
> tomcat applications. I also increased memory for the VM from 4GB to 
> 8GB. Still seeing those. When do we get that errors? I am reading 
> online that when program asks for memory and java cannot give, that's 
> when we see them. Please suggest. Java HotSpot(TM) 64-Bit Server VM 
> (25.20-b23) for linux-amd64 JRE (1.8.0_20-b26), built on Jul 30 2014 
> 13:13:52 by "java_re" with gcc 4.3.0 20080428 (Red Hat
> 4.3.0-8) Memory: 4k page, physical 8061572k(2564740k free), swap 
> 4063228k(4063228k free)
> 
> CommandLine flags: -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/opt/apache/ancillariesmonitoring/logs/
> -XX:InitialHeapSize=128985152 -XX:MaxHeapSize=268435456 -XX:+PrintGC 
> -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers 
> -XX:+UseCompressedOops -XX:+UseParallelGC

Others have commented on those messages you received, but nobody mentioned your 
heap configuration. In the above command-line arguments, you have specified 
both the minimum and maximum heap memory. You have expressed those values in 
bytes which makes it somewhat hard to read what they actually are, but this is 
what you have in readable units:

- -XX:InitialHeapSize=128M -XX:MaxHeapSize=256M

So you aren't using an 8GiB heap. You aren't even using a 4GiB heap.
You are using a 256 *megabyte* heap. If you really want an 8GiB heap, you'll 
need to set it properly in your command-line arguments.

Note that setting the initial heap size to anything other than the maximum heap 
size just makes the JVM take longer to get the heap generations sized 
appropriately. For a long-running server process, I think it never makes any 
sense to set initial < max heap size. Always set them to the same value so that 
the heap itself does not have to be expanded/resized during heap allocations.

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpOYkMdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjKfBAAikZ9mfKhO5VcEGyd
spKC8m4Ot1N+qtkR02ftBf7Sh0CQRjMBFsQUzd2Y+F2w7lPT8bpCnxThKfrkjrkk
ySrF7mVF82aVUM72Abh65tK+E4HJhbZWzGAx7NtSx5XDS5ga9nFvJ42Ea/+pzqUf
ZQmnRIXhj4gWf+q8mk1bIeR0siSc9J7e575CxMkJWji4gIgLgVMMJTZ1Euwya83W
ohTe1Bi355kKiiX3ikRutFgv91fX5kSdNkf+u4huvEBccyDJRaK2MapJ+KOMVUbJ
OodFqlO4eFkeL/KxyclWr8OnAgPj4VaNfaq7jNzZyI5MpZymKhuy8uKnUN10XN8r
tZO/ZFroeEmLDpM6imPIj1eHcgq/emFg1gT9QW8G08WfWFkSF7fm60Xi3U+4/8si
uB3zCFXq9g5EjQ5p2MdpNyQPsHXm5E/J4iS5XyBKkjcuNkVfYneEMP+alOMHIIGI
SxS1Hb54VgV+//etPHgycVVoomw5JFW3erRkiMd6edQL5K9m/j+xHJhbr5nbcYKe
Nj3lPFPQ5hP02qySf+flZQYayX3HNgCXqhFfDDCANKejU7I4ZC2bSySrWrPkuTfc
Dgk+TXlvLRvZ5xWzyM8F1NlsJ/OV+mk23WIyGX7Riyqw9lPghzO+i1mHtyZzg2g8
8zBZXehds+nzTCCBP6MUNqH+I50=
=DPai
-END PGP SIGNATURE-

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

GC allocation failure

[Sanka, Ambica]

I am seeing below highlighted errors in native_err logs in all my tomcat 
applications. I also increased memory for the VM from 4GB to 8GB. Still seeing 
those. When do we get that errors?
I am reading online that when program asks for memory and java cannot give, 
that's when we see them. Please suggest.
Java HotSpot(TM) 64-Bit Server VM (25.20-b23) for linux-amd64 JRE 
(1.8.0_20-b26), built on Jul 30 2014 13:13:52 by "java_re" with gcc 4.3.0 
20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 8061572k(2564740k free), swap 4063228k(4063228k free)
CommandLine flags: -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/opt/apache/ancillariesmonitoring/logs/ 
-XX:InitialHeapSize=128985152 -XX:MaxHeapSize=268435456 -XX:+PrintGC 
-XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
-XX:+UseParallelGC
3.203: [GC (Allocation Failure)  31744K->6311K(121856K), 0.0097261 secs]
3.578: [GC (Allocation Failure)  38055K->12368K(121856K), 0.0089875 secs]
3.756: [GC (Allocation Failure)  44112K->19589K(121856K), 0.0100339 secs]
3.897: [GC (Allocation Failure)  51333K->25872K(153600K), 0.0092326 secs]
4.172: [GC (Allocation Failure)  89360K->38878K(153600K), 0.0152940 secs]
4.417: [GC (Allocation Failure)  102366K->50311K(148480K), 0.0148816 secs]
4.594: [GC (Allocation Failure)  95367K->49903K(151040K), 0.0197327 secs]
4.765: [GC (Allocation Failure)  94959K->50213K(148992K), 0.0149008 secs]
4.946: [GC (Allocation Failure)  96293K->52257K(150528K), 0.0172634 secs]
5.129: [GC (Allocation Failure)  98337K->53118K(151040K), 0.0139426 secs]
5.313: [GC (Allocation Failure)  102270K->53234K(152064K), 0.0122307 secs]
5.498: [GC (Allocation Failure)  102386K->53579K(153088K), 0.0166336 secs]
5.655: [GC (Allocation Failure)  104779K->54486K(153600K), 0.0161735 secs]
6.885: [GC (Allocation Failure)  105686K->51523K(153600K), 0.0123126 secs]

Thanks
Ambica.

RE: java

[Sanka, Ambica]

Steffen,
Is it also possible to test your stuff with jdk1.8.0_51 so that we will know 
something must be wrong with security in jdk1.8.0_51?
Appreciate your help
Ambica.

-Original Message-
From: Sanka, Ambica [mailto:asa...@atpco.net] 
Sent: Monday, July 18, 2016 11:00 AM
To: Tomcat Users List 
Subject: RE: java

Thanks Steffen for letting me know. Did you also post your issue in java 
community? Did you get any response? Currently we are using 1.8.0_45. In the 
future we have requirement to upgrade and got stuck here.

-Original Message-
From: Steffen Heil (Mailinglisten) [mailto:li...@steffen-heil.de]
Sent: Monday, July 18, 2016 10:55 AM
To: Tomcat Users List 
Subject: AW: java

Hi


> With jdk 1.8.0.45 our ldap communication is giving results. As soon as 
> we change tomcat to use jdk1.8.0_51, I am getting below exception. I 
> am not sure security changes in jdk 1.8.0_51 preventing the ldap certificate 
> loaded in cacerts in java not communicating properly to our ldap server.

I am not sure that this related, be we were having issues after updating from 
1.8.0_31 to 1.8.0_72 with certificates signed by root-cas that have a md5 
signature.
While the CA signature in the CA certificate does not provide any security, a 
bug in the jre rejected the certificate even though the certificate itself was 
signed with sha1.
Maybe this is related.


Regards,
   Steffen


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

RE: java

[Sanka, Ambica]

Thanks Steffen for letting me know. Did you also post your issue in java 
community? Did you get any response? Currently we are using 1.8.0_45. In the 
future we have requirement to upgrade and got stuck here.

-Original Message-
From: Steffen Heil (Mailinglisten) [mailto:li...@steffen-heil.de] 
Sent: Monday, July 18, 2016 10:55 AM
To: Tomcat Users List 
Subject: AW: java

Hi


> With jdk 1.8.0.45 our ldap communication is giving results. As soon as we 
> change tomcat to use jdk1.8.0_51, I am getting below
> exception. I am not sure security changes in jdk 1.8.0_51 preventing the ldap 
> certificate loaded in cacerts in java not communicating
> properly to our ldap server. 

I am not sure that this related, be we were having issues after updating from 
1.8.0_31 to 1.8.0_72 with certificates signed by root-cas that have a md5 
signature.
While the CA signature in the CA certificate does not provide any security, a 
bug in the jre rejected the certificate even though the certificate itself was 
signed with sha1.
Maybe this is related.


Regards,
   Steffen

RE: java

[Sanka, Ambica]

Chris,
With jdk 1.8.0.45 our ldap communication is giving results. As soon as we 
change tomcat to use jdk1.8.0_51, I am getting below exception. I am not sure 
security changes in jdk 1.8.0_51 preventing the ldap certificate loaded in 
cacerts in java not communicating properly to our ldap server. People managing 
ldap are mainframe people in our company. I am not able to find root cause so 
that I can give better explanation to them.
Thanks
Ambica.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, July 15, 2016 3:52 PM
To: Tomcat Users List 
Subject: Re: java

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ambica,

On 7/15/16 3:41 PM, Sanka, Ambica wrote:
> Chris, Seems attachment was not sent properly. Here is the trace
> SEVERE: Naming Exception
> occuredjavax.naming.ServiceUnavailableException:
> ldap.atpco.net:636; socket closed; remaining name 
> 'racfid=X,profiletype=user,cn=RACFLDAP,c=us'
> javax.naming.ServiceUnavailableException: ldap.atpco.net:636; socket 
> closed; remaining name 
> 'racfid=X,profiletype=user,cn=RACFLDAP,c=us' at
> com.sun.jndi.ldap.Connection.readReply(Connection.java:449) at
> com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:640) at
> com.sun.jndi.ldap.LdapClient.search(LdapClient.java:563) at
> com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1985) at
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844) at
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at 
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirCont
ext.java:392)
>
> 
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompos
iteDirContext.java:358)
> at
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialComp
ositeDirContext.java:341)
>
> 
at
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:2
67)
> at
> net.atpco.tomcat.racf.service.RacfLDAPService.createLdapInitContext(Ra
cfLDAPService.java:98)
>
> 
at
net.atpco.tomcat.racf.service.TestRacfService.main(TestRacfService.java:
14)
> Jul 15, 2016 3:24:45 PM
> net.atpco.tomcat.racf.service.TestRacfService main INFO: Exception
> occuredjava.lang.Exception: Naming Exception occured

That stack trace doesn't seem to have any Tomcat code in it.

I'm not saying there isn't a Tomcat-related problem.

The core problem seems to be "ServiceUnavailableException". It the LDAP service 
in fact available?

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

iQIcBAEBCAAGBQJXiT72AAoJEBzwKT+lPKRYiGgQALMrc+/0VcX7SfakY4Hy3Oo4
39bMSvvpCk0NyfvVg/6bFzD7+YiDg/keZK9yfrP1d5M7gx19S4Z52QfQDXU88YGw
AAXLxMBYhMjzfe1HpJEwC3Cone6hRRBrTJRbqi+xQBtnCcwsnacrImRv0ew88YJt
Yi1iL6ItoQv0jvYYuMvqzaDGZ/QTZPtpdyixbhn0o4uqNosZBRHlh36OE7KE9k9I
sbP4kb9LpKJkXbaa2mpkjV58i+gn8H/vI2qZF6sVCvA424LHl7VXmfTUQwoOwqSe
MBiWovK8K6Jo+SmmMwi5gVvzbDZ4KjAVjTcOC8uACACrwnyP+4wD4IdVKyCB/GLw
c7jdmdDZXVQGFWjfI6EsqilRHY/MX8xr1N1Y073Uo9WoanEpFRGfa6FQviSlJ8v8
zcdjslRCTadkCP8cyXflNX+q/AlZmbT83k/Oicnd+HIKrMj7i4u3BSbdqNgEp3qg
lkIw7cGvcN+sE4NxqI/rQ9keYZ7G+AJDmGdthYSOQRprE3H+fgrzGLSjxjNL13D6
Wgp+4psqjv+DwdXkJAG1ipzFJHEu16fl/Gi6D1OF3m5KDzRxX0tFld0RSCK956s1
9MVymExa7Gj1fjkOt0ZfLQ+SRWOWbz5OQuec22ImVbjv1DT8+o8ysFQEVQbgZR3/
qBKkFL1ba2qweVE3gibt
=HtRv
-END PGP SIGNATURE-

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

RE: java

[Sanka, Ambica]

Chris,
Seems attachment was not sent properly. Here is the trace
SEVERE: Naming Exception occuredjavax.naming.ServiceUnavailableException: 
ldap.atpco.net:636; socket closed; remaining name 
'racfid=X,profiletype=user,cn=RACFLDAP,c=us'
javax.naming.ServiceUnavailableException: ldap.atpco.net:636; socket closed; 
remaining name 'racfid=X,profiletype=user,cn=RACFLDAP,c=us'
at com.sun.jndi.ldap.Connection.readReply(Connection.java:449)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:640)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:563)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1985)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
at 
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
at 
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
at 
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
at 
javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
at 
net.atpco.tomcat.racf.service.RacfLDAPService.createLdapInitContext(RacfLDAPService.java:98)
at 
net.atpco.tomcat.racf.service.TestRacfService.main(TestRacfService.java:14)
Jul 15, 2016 3:24:45 PM net.atpco.tomcat.racf.service.TestRacfService main
INFO: Exception occuredjava.lang.Exception: Naming Exception occured

Thanks
Ambica.
-Original Message-
From: Sanka, Ambica [mailto:asa...@atpco.net] 
Sent: Friday, July 15, 2016 3:30 PM
To: Tomcat Users List 
Subject: RE: java


Chris,
Thank you for the quick response. Please see the attached for the stack trace.
Thanks
Ambica.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, July 14, 2016 8:59 PM
To: Tomcat Users List 
Subject: Re: java

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ambica,

On 7/14/16 4:31 PM, Sanka, Ambica wrote:
> Does anyone facing issues with security from jdk1.8.0_51 onwards?
> We wrote a Valve in tomcat that connects to our ldap and gets user 
> roles and groups. We connect ldap through ssl certificate. Our ldap 
> ssl Certificate is working  fine till jdk1.8.0_45. From jdk1.8.0_51 , 
> our applications are failing with below error
> 
> SEVERE: Naming Exception occured
> javax.naming.ServiceUnavailableException: ldap.atpco.net:636; socket 
> closed; remaining name
> 
> I also posted this question in java community. But no response.

Can you post the full stack trace? It also looks like the full error message is 
being truncated: "remaining name" looks like it's incomplete.

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

iEYEARECAAYFAleINUUACgkQ9CaO5/Lv0PA/+wCcDpVgXGxY5FCFUn/pWN2SMJbk
2rAAn3/f9EpIvtFAN8v81pwJTTjeNeiY
=Qkh7
-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: java

[Sanka, Ambica]

Chris,
Thank you for the quick response. Please see the attached for the stack trace.
Thanks
Ambica.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, July 14, 2016 8:59 PM
To: Tomcat Users List 
Subject: Re: java

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ambica,

On 7/14/16 4:31 PM, Sanka, Ambica wrote:
> Does anyone facing issues with security from jdk1.8.0_51 onwards?
> We wrote a Valve in tomcat that connects to our ldap and gets user 
> roles and groups. We connect ldap through ssl certificate. Our ldap 
> ssl Certificate is working  fine till jdk1.8.0_45. From jdk1.8.0_51 , 
> our applications are failing with below error
> 
> SEVERE: Naming Exception occured
> javax.naming.ServiceUnavailableException: ldap.atpco.net:636; socket 
> closed; remaining name
> 
> I also posted this question in java community. But no response.

Can you post the full stack trace? It also looks like the full error message is 
being truncated: "remaining name" looks like it's incomplete.

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

iEYEARECAAYFAleINUUACgkQ9CaO5/Lv0PA/+wCcDpVgXGxY5FCFUn/pWN2SMJbk
2rAAn3/f9EpIvtFAN8v81pwJTTjeNeiY
=Qkh7
-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

java

[Sanka, Ambica]

Hi,

Does anyone facing issues with security from jdk1.8.0_51 onwards? We wrote a 
Valve in tomcat that connects to our ldap and gets user roles and groups. We 
connect ldap through ssl certificate. Our ldap ssl Certificate is working  fine 
till jdk1.8.0_45. From jdk1.8.0_51 , our applications are failing with below 
error

SEVERE: Naming Exception occuredjavax.naming.ServiceUnavailableException: 
ldap.atpco.net:636; socket closed; remaining name

I also posted this question in java community. But no response.

Any help is appreaciated.

Thanks in advance,

Ambica.

RE: tomcat8.0.33 classpath/classloader issues

[Sanka, Ambica]

Do you need to add  for your case? Please check
http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html

-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com] 
Sent: Friday, May 27, 2016 1:02 PM
To: Tomcat Users List 
Subject: RE: tomcat8.0.33 classpath/classloader issues

Many thanks Ambica for the detailed information.  Its not working some reason 
for me, when I was debugging the Bootstrap.java class I could clearly see that  
creating common, shared,and catlina loaders as I expected.

While loading the server.xml protocol classes are trying to load then it gets 
failed.I have customized by extending the Http11Protocol but unfortunately 
unable to load the tomcat/lib class(Http11Protocol).


-Original Message-
From: Sanka, Ambica [mailto:asa...@atpco.net]
Sent: 27 May 2016 21:04
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues

We use Tomcat 8.0.9 for our applications. Tomcat server package, we created 
required directories at the same level as conf. We create db2 folder and put 
db2 client jars. Created mq folder and put mq client jars.  We also use some 
property files(name-value pair) and place those files under properties folder. 
Refer that in catalina.properties as below

Then updated catalina.properties as below 
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties"

Our applications work fine. Not sure if this got changed in next versions. 

Ambica.

-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com]
Sent: Friday, May 27, 2016 8:06 AM
To: Tomcat Users List 
Subject: RE: tomcat8.0.33 classpath/classloader issues

Hi,



As Ambica suggested, I have tried by setting different properties 
"common.loader, shared.loader, server.loader"  in catalina.properties but no 
luck. I have tried generating the logs using -Djava.security.debug=all.

Will this security (scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar )  cause 
any problem for class loading while loading the jars?



log4j:WARN No appenders could be found for logger 
(org.apache.tomcat.util.digester.Digester).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.

java.lang.NoClassDefFoundError: 
org/apache/coyote/http11/AbstractHttp11JsseProtocol

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:763)

at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)

at java.net.URLClassLoader.access$100(URLClassLoader.java:73)

at java.net.URLClassLoader$1.run(URLClassLoader.java:368)

at java.net.URLClassLoader$1.run(URLClassLoader.java:362)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:361)

at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

at java.lang.ClassLoader.loadClass(ClassLoader.java:411)

   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:264)

at org.apache.catalina.connector.Connector.(Connector.java:70)

at 
org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:62)

at 
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1178)

at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
Source)

at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)

at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown 
Source)

at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)

at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)

at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)

at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)

at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
Source)

at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)

at org.apache.catalina.startup.Catalina.load(Cat

RE: tomcat8.0.33 classpath/classloader issues

[Sanka, Ambica]

... 37 more





jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  (file:/C:/tomcat8.0.33/bin/bootstrap.jar 
)

sun.misc.Launcher$AppClassLoader@18b4aac2



java.security.Permissions@387c703b (

("java.lang.RuntimePermission" "exitVM")

("java.io.FilePermission" "\C:\tomcat8.0.33\bin\bootstrap.jar" "read")

)



scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  (file:/jre8/lib/ext/tomcat-juli.jar )

sun.misc.Launcher$ExtClassLoader@3ecf72fd



java.security.Permissions@483bf400 (

("java.io.FilePermission" "\C:\jre8\lib\ext\tomcat-juli.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/jre8/lib/ext/tomcat-juli-adapters.jar )

sun.misc.Launcher$ExtClassLoader@3ecf72fd



java.security.Permissions@1fbc7afb (

("java.io.FilePermission" "\C:\jre8\lib\ext\tomcat-juli-adapters.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  (file:/C:/jre8/lib/ext/log4j-1.2.16.jar 
)

sun.misc.Launcher$ExtClassLoader@3ecf72fd



java.security.Permissions@75bd9247 (

("java.io.FilePermission" "\C:\jre8\lib\ext\log4j-1.2.16.jar" "read")

)

scl:

log4j:ERROR Could not find value for key log4j.appender.DEBUG

log4j:ERROR Could not instantiate appender named "DEBUG".

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  (file:/C:/tomcat8.0.33/lib/catalina.jar 
)

java.net.URLClassLoader@520a3426



java.security.Permissions@18eed359 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\catalina.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-util-scan.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@50b494a6 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\tomcat-util-scan.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@6737fd8f (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\tomcat-coyote.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-util.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@5e853265 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\tomcat-util.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/catalina-ha.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@4d3167f4 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\catalina-ha.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/jre8/lib/ext/apache-xercesImpl.jar )

sun.misc.Launcher$ExtClassLoader@3ecf72fd



java.security.Permissions@7a30d1e6 (

("java.io.FilePermission" "\C:\jre8\lib\ext\apache-xercesImpl.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-api.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@7f1302d6 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\tomcat-api.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  
(file:/C:/tomcat8.0.33/lib/tomcat-jni.jar )

java.net.URLClassLoader@520a3426



java.security.Permissions@6973bf95 (

("java.io.FilePermission" "\C:\tomcat8.0.33\lib\tomcat-jni.jar" "read")

)

scl:

jar: beginEntry META-INF/MANIFEST.MF

jar: done with meta!

jar: nothing to verify!

scl:  getPermissions ProtectionDomain  (file:/C:/poc/lib/connect.jar )

sun.misc.Launcher$AppClassLoader@18b4aac2



java.security.Permissions@4445629 (

("java.lang.RuntimePermission" "exitVM")

("java.io.FilePermission" "\C:\poc\lib\connect.jar" "read")

)



Many thanks in advance.







-Ori

RE: tomcat8.0.33 classpath/classloader issues

[Sanka, Ambica]

You can put in catalina.properties. There is entry with common.loader in 
catalina.properties under conf folder. Please see below

# Note: Values are enclosed in double quotes ("...") in case either the
#   ${catalina.base} path or the ${catalina.home} path contains a comma.
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties"

Hope this helps.
Ambica.
-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com] 
Sent: Wednesday, May 25, 2016 5:43 AM
To: Tomcat Users List 
Subject: RE: tomcat8.0.33 classpath/classloader issues

Many thanks Mark. I will give a retry it.
Is there a way to set all jars in folder (c:\poc\lib) to classpath on startup?


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, May 25, 2016 2:25 PM
To: Tomcat Users List
Subject: Re: tomcat8.0.33 classpath/classloader issues

On 25/05/2016 06:14, Venkata Reddy P wrote:
> Can anyone please help me on this?

Don't mess with the classpath. You should (almost) never need to do that.

Put shared JARs in Tomcat's lib directory.

Mark


> 
> From: Venkata Reddy P
> Sent: 24 May 2016 14:44
> To: Tomcat Users List
> Subject: tomcat8.0.33 classpath/classloader issues
> 
> Hi,
> 
> Currently I am migrating my existing tomcat6.0.x to tomcat8.0.33 version.
> 
> 
> 1)  I have deployed four web applications inside webapps folder, all 
> these 4 web applications use the few common jars which I was (in tomcat6.0.x) 
> setting as classpath variable in setclasspath.bat as below
> rem Adding classpath to existing path.
> set CLASSPATH=%CLASSPATH%;%PROJECT_CP%
> 
> %PROJECT_CP% is set by the list of project jars. This way of 
> setting classpath is not working in tomcat8.0.33.  Is it still valid way of 
> setting the classpath in tomcat8.0.x?
> 
> 
> 2)  Some unknown reason when I start tomcat8.0.x server by running 
> \bin\startup.bat,
> 
> Its unable to load the default tomcat jars from \lib\  folder
> 
> Do we have any limitation in tomcat8.0.33 version?
> 
> 
> 
> In both 1) and 2) cases if I have copy all the required jars to primary roo 
> class loader \ext\lib folder, then it is loading all the jars as 
> expected. The way of loading through the jre folder is not good practice in 
> my project to separate the jars.
> 
> 
> 
> Could you please help why default tomcat jars not loading and classpath is 
> not working in tomcat8.0.33 version?
> 
> Many Thanks in advance.
> 


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


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


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

RE: memory leak in Tomcat 8.0.9

[Sanka, Ambica]

Hi Mark,
Thanks for your response. Doesn't tomcat stop take care of shutting down all 
the threads? Do we need to handle explicity this case?
Thanks
Ambica.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, May 20, 2016 9:34 AM
To: Tomcat Users List 
Subject: Re: memory leak in Tomcat 8.0.9

First of all, the subject is wrong. There is no memory leak in Tomcat.
There is a memory leak in the application you are running on Tomcat.

On 20/05/2016 14:21, Sanka, Ambica wrote:
> 2016-05-19 14:03:31,161 [localhost-startStop-2] WARN  
> org.apache.catalina.loader.WebappClassLoader- The web application 
> [/fmDirectoryService] appears to have started a thread named [Thread-6] but 
> has failed to stop it. This is very likely to create a memory leak. Stack 
> trace of thread:
> 
> java.lang.Thread.sleep(Native Method)
> 
> net.atpco.cluster.support.BaseLocator$AdminTask.run(BaseLocator.java:1
> 41)

What isn't clear in the message above?

Based on the Java package name and your e-mail address 
net.atpco.cluster.support.BaseLocator is code that you control.
BaseLocator starts a thread so it needs to stop that thread when the web 
application shuts down. ServletContextListener.contextDestroyed() is usually 
where such clean-up is performed.

Mark

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


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

memory leak in Tomcat 8.0.9

[Sanka, Ambica]

Support Team,

We have been using Tomcat 8.0.9 for our applications. We noticed below memo= ry 
leak error and out tomcat could not stopped. We had to kill the process = 
manually. I was reading articles in the internet and this got address after=  
tomcat 6. But we found error in higher versions. We are not sure where to = fix 
this? Below is the error we are getting

2016-05-19 14:03:31,161 [localhost-startStop-2] WARN  org.apache.catalina.l=

oader.WebappClassLoader- The web application [/fmDirectoryService] appears = to 
have started a thread named [Thread-6] but has failed to stop it. This i= s 
very likely to create a memory leak. Stack trace of thread:

java.lang.Thread.sleep(Native Method)

net.atpco.cluster.support.BaseLocator$AdminTask.run(BaseLocator.java:141)

2016-05-19 14:03:31,197 [localhost-startStop-2] INFO  org.apache.catalina.c=

ore.ContainerBase.[Catalina].[localhost].[/fmbootstrap]- Destroying Spring = 
FrameworkServlet 'dispatcherServlet'

2016-05-19 14:03:31,210 [localhost-startStop-2] INFO  org.apache.catalina.c=

ore.ContainerBase.[Catalina].[localhost].[/fmbootstrap]- Closing Spring roo= t 
WebApplicationContext

2016-05-19 14:03:31,210 [localhost-startStop-2] INFO  org.springframework.b=

oot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext- Closing=  
org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebAppli=

cationContext@5e119034=

otationConfigEmbeddedWebApplicationContext@5e119034>: startup date [Thu May=

19 08:17:39 EDT 2016]; root of context hierarchy May 19, 2016 2:03:31 PM 
com.mongodb.util.management.jmx.JMXMBeanServer unre= gisterMBean

WARNING: Unable to register MBean org.mongodb.driver:type=3DConnectionPool,=

clusterId=3D1,host=3Dlocalhost,port=3D27017

javax.management.InstanceNotFoundException: org.mongodb.driver:type=3DConne=

ctionPool,clusterId=3D1,host=3Dlocalhost,port=3D27017

at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(D=

efaultMBeanServerInterceptor.java:1095)

at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveU=

nregisterMBean(DefaultMBeanServerInterceptor.java:427)

at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregister=

MBean(DefaultMBeanServerInterceptor.java:415)

at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanS=

erver.java:546)

at com.mongodb.util.management.jmx.JMXMBeanServer.unregisterMBean(J=

MXMBeanServer.java:52)

at com.mongodb.JMXConnectionPoolListener.connectionPoolClosed(JMXCo=

nnectionPoolListener.java:68)

at com.mongodb.PooledConnectionProvider.close(PooledConnectionProvi=

der.java:107)



Any kind of help is appreciated.

Thanks

Ambica.