Unable to access Manager App from remote machine

[Nick Klose]

Hello,

I have recently set up Tomcat 8.5.4 on Ubuntu 14.04. I have the default
page showing on port 8080, but when I click on the Manager App button I
immediately get "403 Access Denied" and am not prompted to enter a username
or password. I have set up roles and a user in conf/tomcat-users.xml in my
Tomcat install directory (which I have named /opt/tomcat8-dev). Here's what
that file looks like:

http://tomcat.apache.org/xml;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">








The server I'm running it on is a remote VM without a window manager,
however I installed elinks (a command-line web browser) and tested the
Manager App and it worked fine there; I was asked for credentials, and was
able to view the app using the username/password I specified. However, this
is obviously not an ideal solution.

I have tried modifying context.xml as specified in the documentation. I
have enabled privileged mode and added a valve allowing any IP to connect
(specified using a regex). Here's what my context.xml file looks like
currently:



​​

​
WEB-INF/web.xml
​
​​
${catalina.base}/conf/web.xml



Any suggestions for how I can fix this issue?

Thanks,
Nick Klose​

tomcat-extras

[Timothy Stewart]

I'm not able to download the artifact for (maven):


org.apache.tomcat.extras
tomcat-extras-juli
8.5.4


org.apache.tomcat.extras
tomcat-extras-juli-adapters
8.5.4


Also the download links at http://tomcat.apache.org/download-80.cgi#8.5.4
for juli-adapters and log4j-juli give a 404.

Have these packages been removed or relocated?

Thanks.

- Tim Stewart.

Re: OutOfMemoryError: PermGen space

[Mark Thomas]

On 20/07/2016 17:31, Berneburg, Cris J. - US wrote:
> Mark
> 
> Thanks again for taking the time to educate me and answer my
> questions.  My lengthy replies below.  To summarize, our app does not
> seem to commit any egregious memory leak offenses, from what I can
> tell so far.  I plan to heap dump an older version of the app that
> does not use third-party libraries for comparison purposes.

This should help:
http://markmail.org/message/fcbvwapt6afyndxn

One thing worth noting. Yourkit offers two types of heap dumps. You
don't want YourKit's own. There is a JVM bug that prevents some GC roots
from being shown in that format and if your leak traces back to one of
those you can end up scratching your head for days.

Mark

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

Re: NullPointerExceptions from Coyote over SSL

[Peter Robbins]

That’s good to know. In the short term I think we’re going to revert back to 
the 8.0.x branch and see if we can find put together a more isolated repro war 
to try to nail this thing down. Thanks for your help!

Peter

On 7/20/16, 7:40 AM, "Rémy Maucherat"  wrote:

2016-07-20 13:59 GMT+02:00 Peter Robbins :

> Ok I'll see if I can dig BC out of the application and have it actually
> start up to try to see if that's the case.
>
> You're saying there are known compatibility issues with Tomcat NIO https
> if you register another j2ee security provider?


No, but we're not testing that kind of configuration at all. Since there's
OpenSSL support, it seems less important now as well.


> The errors we're seeing don't seem crypto related apart from only
> appearing over https.
>

Rémy

No binary distribution for mod_jk?

[Paul Roubekas]

I am trying to install the mod_jk on httpd for my tomcat 7.0.68 (TomEE)
server.

I am reading this
https://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
documentation which points to this
http://tomcat.apache.org/download-connectors.cgi download page.  But
there is no binary download for *unix, just source?




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

RE: OutOfMemoryError: PermGen space

[Berneburg, Cris J. - US]

Mark

Thanks again for taking the time to educate me and answer my questions.  My 
lengthy replies below.  To summarize, our app does not seem to commit any 
egregious memory leak offenses, from what I can tell so far.  I plan to heap 
dump an older version of the app that does not use third-party libraries for 
comparison purposes.


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, July 19, 2016 3:15 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 19/07/2016 17:19, Berneburg, Cris J. - US wrote:
> 
> 
> 
> >> This is probably a useful read:
> >> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks
> >> -60mins.pdf
> >>
> >> Despite the age, it is still very relevant today.
> > 
> > 
> > Thanks for reminding me about that document.  It does sound relevant.  
> > The document says,
> > 
> >> How memory leaks occur: Reference chains [...] Retaining a reference 
> >> to a single object from a web application pins every class loaded by 
> >> the web application in the Permanent Generation
> > 
> > Practically speaking, how is a reference retained?
> > 1. Is a module-level (member) variable in a Servlet an example?
> 
> No. Assuming the class that defines the Servlet is packaged with the
> web application (i.e. in a JAR in WEB-INF/lib or in WEB-INF/classes


All our servlets are classes in WEB-INF/classes.


> > 2. How about using ServletContext.setAttribute without an accompanying
> > removeAttribute?
> 
> No.
> 
> > 3. I see in one of my listeners some member (module-level) variables:
> > a private static for the logger and also a protected final String.
> > Is that a problem?
> 
> No.


Dang, I was hoping that would be it.  :-)


> > If you could provide a little more guidance about the details, I would
> > appreciate it.
> 
> Sure.
> 
> There are two categories of objects we are concerned about. Objects
> defined by classes that are provided by your web application (in
> WEB-INF/lib or WEB-INF/classes) and objects defined by classes that
> are provided by the container (Tomcat) or the JVM.
> 
> References from web application objects to web application objects
> are fine.
> 
> References from web application objects to container objects are fine.
> 
> References from container objects to web application objects are
> potentially a problem.
> 
> Additionally, references from container objects to the web application
> class loader are potentially a problem.


Hmm... I'm gonna need some time to absorb that.


> For example:
> 
> When you start a thread in a web application, the thread context
> class loader will be the web application class loader and the thread
> holds a reference to this. If the thread is not stopped when the web
> application is stopped there will be a reference held to the web
> application class loader which will cause a leak.


To my knowledge we are not explicitly starting any new threads.  Our app is 
pretty basic.


> If you add a logging framework to Tomcat's lib directory and then
> package a custom log formatter with your web application, the formatter
> will be registered with the logging framework and unless you unregister
> it when the application stops there will be reference from logging
> framework to custom formatter object to custom formatter class to web
> application class loader which will cause a leak.


We did not program a custom formatter with LOG4J2, just used a format parm in 
the config.  Also, LOG4J jar files were added the to the app WEB-INF/lib 
folder, not Tomcat's.

Sounds like there are a lot of potential sources for memory leaks.  I'm either 
going to have to keep digging deeper using a heap dump tool or simply punt 
without figuring it out.  Will a heap dump analyzer reveal what instances are 
in PermGen space and what has references to them?  Maybe I can follow up a 
chain of references to determine the source.

In the heap dump the largest collection of instances is java.lang.String.  
Could concatenation by assignment be a problem?  Example, abc = abc + xzy.  
While we are guilty of that, performing a heap dump on a fresh, idle, unused 
app would not have called the offending code.  So that cannot be it.

The second and third largest groups of instances in the heap dump are char[] 
and java.util.HashMap$Entry.  They must be from a library or third-party class, 
since not one char or HashMap instance is declared in our entire application.

As an experiment, I may grab heap dumps from and restart an older version of 
the app that does not use Mybatis or Log4J to see how that affects the top 3 
class instances.  If the sizes are significantly smaller, then perhaps the 
leaks are from those libraries.

FYI, I was pretty careful in taking the previous advice from this group about 
using the try-open/catch/finally-close paradigm when opening and closing each 
DB connection from Mybatis to prevent connection-related memory leaks.  My 
intent was that connection references are 

RE: OutOfMemoryError: PermGen space

[Berneburg, Cris J. - US]

Hi Guido

Thanks for taking the time to answer my questions and make suggestions.  My 
replies below.


-Original Message-
From: Jäkel, Guido [mailto:g.jae...@dnb.de] 
Sent: Tuesday, July 19, 2016 10:31 AM
To: 'Tomcat Users List'
Subject: RE: OutOfMemoryError: PermGen space

>> In Visual VM, under File, Compare Memory Snapshots, it does not see the 
>> snapshots I generated.  The snapshots appear to be extension *.apps, 
>> but the compare function looks for files with extension *.nps.  I don't
>> know how to get the compare function to work.
>> 
>> Not sure where to go from here.  Got any suggestions?
> 
> You may pull heap dumps and use the Eclipse Memory Analyzer Toolkit (aka
> MAT)  (http://www.eclipse.org/mat/) to discover stale objects danging on
> the webapps classloader. The tool may be used stand-alone (via an included
> Eclipse RCP) or as an Eclipse Plugin.


Thanks for the suggestion.  I've never used that tool before.  Will it read the 
heap dumps generated by Visual VM?  I'll either try MAT or see if IntelliJ Idea 
has one, since Idea is my IDE.


[SNIP]

> If possible in any way, please upgrade to (Oracle) Java 1.8, because to
> my experience, there seems even notable fixes inside the Java core
> libraries. And enable the newest "G1" garabarge collector, too. Without
> changing any line in our apps, the JVM heap usage was notable smaller
> and smoother. Because of migrating with the [...] VM, the PermGen-Heap
> have been replaced by the Metaspace-Heap. Some parts of allocation now
> in the main heap and is reclaimable, some other remain. But technical,
> the Metaspace heap is now handled as all others, therefore it has no
> real separate size. You may set (and should) a limit, but per default
> it's unlimitied within the main heap.


I plan on upgrading to Java 1.8 soon but not quite yet, hoping to figure this 
out before doing so.  I don't want to change something that could potentially 
make the symptom go away but simply hide the underlying problem.

Thanks for reminding me about G1.  Is there any reason not to enable G1 garbage 
collection?  Also, Google says that there are potentially 3 ways of enabling it:

1. Customizing the Tomcat startup procedures to add the -XX:+UseG1GC option.  
This requires modifying the Tomcat startup every time you install Tomcat.

2. Setting the JAVA_TOOL_OPTIONS Java environment variable.  This makes G1 
default for all Java applications.

3. Setting the JAVA_OPTS environment variable that Tomcat might look for?  Not 
sure about this one.


> Greetings
> 
> Guido

--
Cris Berneburg, Lead Software Engineer, CACI

Re: NullPointerExceptions from Coyote over SSL

[Rémy Maucherat]

2016-07-20 13:59 GMT+02:00 Peter Robbins :

> Ok I'll see if I can dig BC out of the application and have it actually
> start up to try to see if that's the case.
>
> You're saying there are known compatibility issues with Tomcat NIO https
> if you register another j2ee security provider?


No, but we're not testing that kind of configuration at all. Since there's
OpenSSL support, it seems less important now as well.


> The errors we're seeing don't seem crypto related apart from only
> appearing over https.
>

Rémy

Re: NullPointerExceptions from Coyote over SSL

[Peter Robbins]

Ok I'll see if I can dig BC out of the application and have it actually start 
up to try to see if that's the case.

You're saying there are known compatibility issues with Tomcat NIO https if you 
register another j2ee security provider? The errors we're seeing don't seem 
crypto related apart from only appearing over https.

On Jul 20, 2016 1:56 AM, R?my Maucherat  wrote:
2016-07-20 2:54 GMT+02:00 Peter Robbins :

> Without JCE or BC? Both are pretty critical for core functionality and
> didn't cause any issues until 8.5.3 entered the mix. Any known issues there
> I should be aware of?
>

You still need to test something. You don't describe anything out of the
ordinary other than that and we don't get issues at all with 8.5, so an
investigation has to start somewhere.

Why is BC critical for core functionality ? JSSE doesn't work for you ? Is
tomcat-native installed [OpenSSL could be used if that is the case] ?

R?my

Re: NullPointerExceptions from Coyote over SSL

[Rémy Maucherat]

2016-07-20 2:54 GMT+02:00 Peter Robbins :

> Without JCE or BC? Both are pretty critical for core functionality and
> didn't cause any issues until 8.5.3 entered the mix. Any known issues there
> I should be aware of?
>

You still need to test something. You don't describe anything out of the
ordinary other than that and we don't get issues at all with 8.5, so an
investigation has to start somewhere.

Why is BC critical for core functionality ? JSSE doesn't work for you ? Is
tomcat-native installed [OpenSSL could be used if that is the case] ?

Rémy

Re: Tomcat Log file setting.

[Daniel Küppers]

James,
i think this is either a Log4j error or a custom one. It seems like the 
path for *IDOMailLOCAL1.log* is hard coded, as it's not present in the 
Log4j config file.
I would suggest you search your codebase for pattern like *IDOMail* 
(because the LOCAL1 might be generic, imho) or for the drive letter *D:*.

If that doesnt bring something up, try the Log4j user-list:

https://logging.apache.org/log4j/1.2/mail-lists.html

greetings

Daniel

Am 19.07.2016 um 23:33 schrieb Boyle, James A:

Hello,
I have a web app running on my workstation using Tomcat 7 and 
have the following entries in my console output. Any help would be appreciated. 
Thanks.

INFO: Initializing log4j from 
[file:///c://lbxdw_ido_obm//conf//LOCALlog4j_JAB.xml] This is the log4j config 
file and is a good file.
log4j:ERROR setFile(null,true) call failed. Not sure why this is being 
generated. I specify the Error appender in the config file appropriately
java.io.FileNotFoundException: D:\Apps\Tomcat 7.2\logs\IDOMailLOCAL1.log (The 
device is not ready) This is the issue. My D drive is the DVD drive, but the 
kicker is that I cant find anywhere in my app or within Tomcat where this 
setting is being made. Nothing residual in the registry. Is there some sort of 
.ini file that I am missing?

Log4j config file

http://jakarta.apache.org/log4j/; 
debug="true">

   
   
  
   


   
   
   
  
   


   
   
   
  
   


   
   


Jim Boyle
Wholesale Lockbox Technology
Bank of America
(617) 533-4532
james.a.bo...@baml.com

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.




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