Re: I can only access Tomcat 7 when running via console (startup.bat)

[Yuri E]

2012/12/11 André Warnier 

> Yuri E wrote:
>
>>
>>>  I added a exception for the 8080 port in the Windows XP Firewall
>> settings.
>> Tomcat is working now.
>> Thanks for all the answers.
>>
>>
> Yuri, for me that still does not explain why you could access Tomcat from
> "outside" when it was running in a console, but not when it was running as
> a service.
> Just opening port 8080 should either allow both, or none.
> Something here doesn't fit.
>

I know that's weird, but It's the exactly what happens to me.

Firewall status:
- on -> only the "console way" is accessible from Internet (outside my
local network)
- on, with 8080 port added to "Exceptions List" (Exceptions tab in Firewall
Settings) -> both ways are accessible from Internet
- off -> both ways are accessible from Internet



> Or what exception exactly did you add ?
>
>
>
I went to Windows Firewall Settings window, then, in the "Exceptions" tab,
I added the 8080 port (I also named as TomcatTCP) with the "TCP" option
selected, then I added the 8080 port again (named as TomcatUDP) with the
"UDP" option selected.

After all this, two itens were added to the Exceptions List: TomcatTCP and
TomcatUDP. Then I could access Tomcat (so my app too) from global Internet
(using the router's IP).


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

Re: I can only access Tomcat 7 when running via console (startup.bat)

[André Warnier]

Yuri E wrote:



I added a exception for the 8080 port in the Windows XP Firewall settings.
Tomcat is working now.
Thanks for all the answers.



Yuri, for me that still does not explain why you could access Tomcat from "outside" when 
it was running in a console, but not when it was running as a service.

Just opening port 8080 should either allow both, or none.
Something here doesn't fit.
Or what exception exactly did you add ?


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

Re: I can only access Tomcat 7 when running via console (startup.bat)

[Yuri E]

2012/12/11 Christopher Schultz 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuri,
>
> On 12/10/12 11:22 PM, Yuri E wrote:
> > 2012/12/10 Daniel Mikusa 
> >
> >> On Dec 10, 2012, at 11:28 AM, André Warnier wrote:
> >>
> >>> Yuri E wrote:
>  2012/12/7 André Warnier 
> > Christopher Schultz wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> >>
> >> André,
> >>
> >> On 12/7/12 1:55 PM, André Warnier wrote:
> >>
> >>> I am relatively familiar with tomcat under Windows,
> >>> and if your explanations of what works and what
> >>> doesn't above are exact, then I don't know either.
> >>>
> >> One possibility: during the installation, the user chose
> >> to bind only to localhost instead of 0.0.0.0.
> >>
> > Aaaah. Yes, and that choice probably only exists in the
> > Service
> >> installer.
> > That would fit. And he would see that with netstat.
> >
> >>
>  "netstat -abn" results: -- running Tomcat on console: TCP
>  0.0.0.0:8009   0.0.0.0:0  LISTENING
> >> 3844
>  [java.exe] TCP0.0.0.0:8080   0.0.0.0:0 LISTENING
> >> 3844
>  [java.exe] TCP127.0.0.1:8005 0.0.0.0:0 LISTENING
> >> 3844
>  [java.exe] -- running Tomcat as Service: TCP0.0.0.0:8009
>  0.0.0.0:0  LISTENING
> >> 488
>  [Tomcat7.exe] TCP0.0.0.0:8080   0.0.0.0:0
>  LISTENING
> >> 488
>  [Tomcat7.exe] TCP127.0.0.1:8005 0.0.0.0:0
>  LISTENING
> >> 488
>  [Tomcat7.exe]
> >>>
> >>> Well, Chris, that was a worthy guess, but apparently it is not
> >>> the
> >> reason here.
> >>>
> >>> Didactic section :
> >>>
> >>> In both cases above (running in a console window and running
> >>> as a
> >> Service), we have Tomcat listening :
> >>> - on port 8080, all interfaces, all IP addresses.  That's the
> >>> HTTP
> >> Connector
> >>> (see in server.xml) - on port 8009, all interfaces, all IP
> >>> addresses.  That's the AJP
> >> Connector
> >>> (see in server.xml) (and maybe you don't need that one, and
> >>> can
> >> comment it out)
> >>> - on port 8005, only on the "localhost" address.  That is the
> >>> "shutdown
> >> port", which is limited to listening for calls originating from
> >> the same physical host, for security reasons (so that nobody can
> >> shut down your Tomcat from the internet e.g.)
> >>>
> >>> And the reason why in one case the process is "Tomcat7.exe"
> >>> and in the
> >> other case it is "java.exe" :
> >>> - when Tomcat runs as a Service, there is a "service wrapper"
> >>> involved,
> >> which "wraps around" the java process (and Tomcat in it), and
> >> which provides the special functions that Windows Services must
> >> provide for Windows (like listening to Windows "star/stop
> >> service" messages etc..). This wrapper is a copy of the
> >> procrun.exe program, renamed to "tomcat7.exe" for convenience.
> >>> So when you run Tomcat as a Service, Windows really starts
> >> "tomcat7.exe", and tomcat7.exe runs java.exe which runs tomcat.
> >>>
> >>> -- end of didactic section --
> >>>
> >>>
> >>> To summarise what is happening now :
> >>>
> >>> 1) Tomcat running in a console window : a) can be accessed
> >>> from a browser running on the same machine b) can be accessed
> >>> from a browser running on another machine
> >>>
> >>> 2) Tomcat running as a Windows Service : a) can be accessed
> >>> from a browser running on the same machine b) but cannot be
> >>> accessed from a browser running on another machine
> >>>
> >>> while in both cases it is listening to 0.0.0.0:8080
> >>>
> >>> It it was a DNS issue, then both 1-b and 2-b wouldn't work.
> >>> But only 2-b
> >> doesn't work.
> >>> If it was a firewall issue or similar, we'd have the same. If
> >>> it was an issue of the java parameters or others used when
> >>> starting
> >> tomcat as a service, then both 2-a and 2-b would not work. But
> >> 2-a works.
> >>>
> >>> Some weird MS security rule, applying to services but not to
> >>> regular
> >> processes ?
> >>>
> >>> Yuri, can you repeat for us which exact URL's you are using to
> >>> access
> >> Tomcat, in each of the cases above ?
> >>>
> >>> 1-a : 1-b : 2-a : 2-b :
> >>>
> >>> and how the problem shows up, when "it does not work" ?
> >>
> >> Also, if you have a firewall running on the server, how is it
> >> configured? Do you have a rule to allow tcp on port 8080?  I ask
> >> because some firewalls will restrict at the application level as
> >> well as the port level. For example, only "java.exe" is allowed
> >> to listen on port 8080.
> >>
> >> Dan
> >>
> >>
> >>>
> >>>
> >>> -
> >>>
> >>>
> >>>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>
> >>
> >> -
> >>
> >>
> >>
> To unsubscribe,

Re: Request dispatching oddity

[Mark Thomas]

On 11/12/2012 22:00, Christopher Schultz wrote:
> Can you start a new thread with a different subject? Something
> like "Tomcat prefers TC JSTL implementation to webapp-packaged one"
> and ask about it? I know there are some folks here who can describe
> how that's supposed to work. Once you've got that hammered-out (or
> maybe in parallel), you can ask about why the  tag
> doesn't work.
> 
> A new thread and subject line may get others interested, which is
> why I am suggesting it.

Chances are you are using an Oracle authored tag library derived from
the ASF's JSTL implementation that (ab)uses the ASF package namespace.

The Apache Tomcat PMC asked Oracle to change the Java package name tp
avoid confusion and they refused. They did, however, agree to ensure
that JARs contained appropriate META-INF entries so it was clear where
the JAR originated.

Mark

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

Re: Request dispatching oddity

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Juha,

On 12/11/12 3:29 PM, Juha Laiho wrote:
> first, thanks for your answers, and also for the nits, they did
> hit some good points. Then on with some answers to the further 
> questions you placed;
> 
> 
> On Tue, Dec 11, 2012 at 12:58 AM, Christopher Schultz 
>  wrote:
>> On 12/10/12 5:40 PM, Christopher Schultz wrote:
>>> I'll take a look. You definitely want to use URLs that start
>>> with "/" in all cases to prevent this kind of ambiguity.
>> 
>> So it looks like I'm wrong and there may in fact be a bug in
>> Tomcat.
>> 
>> Servlet 3.0 has this to say about "forward" in section 9.4:
>> 
>> " The path elements of the request object exposed to the target
>> servlet must reflect the path used to obtain the
>> RequestDispatcher. "
> 
> Thanks, I did read the Servlet spec 2.5, but at least didn't come
> across this statement there.
> 
>> Your forward() code looks like this:
>> 
>>> RequestDispatcher rd = application.getRequestDispatcher("/"); 
>>> rd.forward(request, response);
>> 
>> So the path used to obtain the RequestDispatcher is "/" and URLs
>> built should be relative to that.
> 
> ... so looks like I might have encountered a minor bug.

Perhaps.

>> Are you using Tomcat's provided JSTL, or do you bundle one with
>> your own webapp?
> 
> This was good call, too - something I hadn't been paying attention
> to. In the example I seem to be using JSTL library from some
> version of Glassfish (a Maven dependency, javax.servlet:jstl:1.2,
> which gets packaged into the examle webapp). What JSTL
> implementation is used in the original place where I encountered
> this, I don't know (could check, but I think for now we can just as
> well concentrate on this example, as it exhibits the same behaviour
> as the original case).

Odd that Tomcat's JSTL implementation was used in preference to the
one supplied with the webapp.

>> Can you post a copy of the .java source generated from your JSP
>> that contains the ?
> 
> Certainly; and this seems to hit another point where I've been
> sloppy; this example has been run on Tomcat embedded with NetBeans,
> and thus version 7.0.27. And interesting, this seems to refer to 
> org.apache.taglibs.standard for the RegirectTag implementation,
> despite the other JSTL lib being included in the application:

There's also a Redirect class in Tomcat proper which generates Java
source instead of being an actual tag implementation. I was actually
thrown-off the by that.

Tomcat's taglibs are actually maintained under a slightly different
umbrella and it's unclear to me if they are actively maintained. There
are svn revisions, but they all seem to be deployment-related and not
actual code changes.

Can you start a new thread with a different subject? Something like
"Tomcat prefers TC JSTL implementation to webapp-packaged one" and ask
about it? I know there are some folks here who can describe how that's
supposed to work. Once you've got that hammered-out (or maybe in
parallel), you can ask about why the  tag doesn't work.

A new thread and subject line may get others interested, which is why
I am suggesting it.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHrOYACgkQ9CaO5/Lv0PDrKACgiF7MJ/opHRg1rqM7ol71dWIs
AvAAnjfLlQbrKZ3kqJD0NHu7zcPoaWHL
=wP1M
-END PGP SIGNATURE-

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

Re: JMX with Listener

[André Warnier]

Cédric Couralet wrote:
...


One question, though, in the tomcat doc (for 6.0.x) for the
JMXRemoteListener, the configuration is :

-Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/jmxremote.access

while mine is 
-Dcom.sun.management.jmxremote.password.file=${CATALINA_BASE}/conf/jmxremote.password
(notice the {} ).

is it my mistake?




No, it is not a mistake.  The above are lines extracted from a shell script, I 
presume.
In this particular case, $CATALINA_BASE and ${CATALINA_BASE} are equivalent.
The {} form helps to clarify things for the shell when the character which *follows* the 
name of the variable, could be considered by the shell as part of the variable name.

For example in :

echo "something" > $my_file_conf

it is not clear whether the name of the variable is "my" or "my_file" or 
"my_file_conf".
(or anything in-between), and by default the shell will use the longer 
possibility.

Writing this as

echo "something" > ${my_file}_conf

leaves only one possible interpretation.

In "$CATALINA_BASE/conf/jmxremote.password" there is really no ambiguity (because "/" 
cannot be part of a variable name), but the form 
"${CATALINA_BASE}/conf/jmxremote.password" is anyway clearer and less prone to oversights.
(But it is slightly more work to type, and as programmers are a notoriously lazy and 
hubristic bunch, they rarely go through the trouble).


I suppose that - just to kid Christopher - I could on like this, talking about 
interpolation and stuff, but I'll leave it at that because it's already late here.




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

Re: Revoked Certificate being accepted

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Will,

On 12/11/12 2:53 PM, Will Nordmeyer wrote:
> On Tue, Dec 11, 2012 at 2:25 PM, Christopher Schultz 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Will,
>> 
>> On 12/11/12 11:43 AM, Will Nordmeyer wrote:
>>> I have my Tomcat 6.0.34 installation configured to use APR and 
>>> tcnative for certificate valiation & CRL checking.
>>> 
>>> I have a revoked CRL and when I use the openssl command line
>>> to check the certificate, it properly returns certificate
>>> revoked.
>> 
>> You mean a revoked cert, right? I don't think you can revoke a
>> CRL. (Would that un-revoke the certs in the list...?)
>> 
>>> When I try going in through tomcat, however, it prompts for a 
>>> certificate to be selected and then once I select the revoked 
>>> certificate, it lets me into the application.
>> 
>> Did you start the server, revoke the certificate, then attempt to
>> use it to gain access? Tomcat loads the CRL once at startup when
>> using JSSE, so I assume the same thing happens with the APR
>> connector.
>> 
>> If you restart Tomcat with no other changes, is the connection
>> blocked?
>> 
>>> ]# openssl verify -CApath /etc/ssl/certs -crl_check_all
>>> -verbose -purpose sslclient TestThirtySeven_Revoked.pem 
>>> TestThirtySeven_Revoked.pem: C = US, O = , OU = OU1, OU =
>>> OU2, OU = OU3, CN = TESTThirtySeven.REVOKED.950001 error 23
>>> at 0 depth lookup:certificate revoked
>>> 
>>> Connector info from Tomcat: >> protocol="org.apache.coyote.http11.Http11AprProtocol" 
>>> SSLEnabled="true" scheme="https" maxHttpHeaderSize="8192" 
>>> maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
>>> enableLookups="false" acceptCount="100" 
>>> disableUploadTimeout="true" compression="on" 
>>> compressableMimeType="text/html,text/xml,text/plain,text/css,text/
>>>
>>> 
javascript,application/xml,application/x-javascript,application/javascript"
>>> 
>>> 
>> connectionTimeout="2"
>>> secure="true"
>>> SSLCertificateFile="/etc/ssl/certs/servercrt01.crt" 
>>> SSLCertificateKeyFile="/etc/ssl/certs/serverkey.pem" 
>>> SSLPassword="password" SSLCACertificatePath="/etc/ssl/certs/" 
>>> SSLVerifyClient="require"
>>> SSLCARevocationPath="/etc/ssl/certs/" sslProtocol="TLS"
>>> redirectPort="8443" />
>>> 
>>> The log file shows nothing related to CRL.
>>> 
>>> The /etc/ssl/certs directory has hash links to my CAs and
>>> CRLs.
>> 
>> You mean symlinks?
>> 
> 
>>> Does it help if I hit the server with a baseball bat?
>> 
>> If I'm right (above), and the baseball bat causes a reboot
>> without any other damage, then it might actually help.
>> 
>> I don't believe Tomcat has any current mechanism for refreshing
>> the CRL. I think that's been requested once or twice... not sure
>> if it's actually in Bugzilla. If it's not, it should be: care to
>> look and file the enhancement request if necessary?
>> 
> OK... hit me with the baseball bat - I forgot to restart tomcat.
> I've read those steps repeatedly and forgot when it was important.

It's probably still worth filing such an enhancement request. Bouncing
the whole app server just to re-read the CRL is a bit heavy-handed.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHo/4ACgkQ9CaO5/Lv0PC3VACcCRNtiZW2WQ9Mww6EMDRz5Nf6
t5kAn0JcBU3cxXMKC6KJyue9QyY9v44t
=5Qax
-END PGP SIGNATURE-

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

Re: Request dispatching oddity

[Juha Laiho]

Chirs,

first, thanks for your answers, and also for the nits, they did hit
some good points. Then on with some answers to the further
questions you placed;


On Tue, Dec 11, 2012 at 12:58 AM, Christopher Schultz
 wrote:
> On 12/10/12 5:40 PM, Christopher Schultz wrote:
>> I'll take a look. You definitely want to use URLs that start with
>> "/" in all cases to prevent this kind of ambiguity.
>
> So it looks like I'm wrong and there may in fact be a bug in Tomcat.
>
> Servlet 3.0 has this to say about "forward" in section 9.4:
>
> "
> The path elements of the request object exposed to the target servlet
> must reflect the path used to obtain the RequestDispatcher.
> "

Thanks, I did read the Servlet spec 2.5, but at least didn't come across
this statement there.

> Your forward() code looks like this:
>
>> RequestDispatcher rd = application.getRequestDispatcher("/");
>> rd.forward(request, response);
>
> So the path used to obtain the RequestDispatcher is "/" and URLs built
> should be relative to that.

... so looks like I might have encountered a minor bug.

> Are you using Tomcat's provided JSTL, or do you bundle one with your
> own webapp?

This was good call, too - something I hadn't been paying attention to.
In the example I seem to be using JSTL library from some version of
Glassfish (a Maven dependency, javax.servlet:jstl:1.2, which gets
packaged into the examle webapp). What JSTL implementation is used
in the original place where I encountered this, I don't know (could check,
but I think for now we can just as well concentrate on this example, as
it exhibits the same behaviour as the original case).

> Can you post a copy of the .java source generated from your JSP that
> contains the ?

Certainly; and this seems to hit another point where I've been sloppy; this
example has been run on Tomcat embedded with NetBeans, and thus
version 7.0.27. And interesting, this seems to refer to
org.apache.taglibs.standard
for the RegirectTag implementation, despite the other JSTL lib being
included in the application:


/*
 * Generated by the Jasper component of Apache Tomcat
 * Version: Apache Tomcat/7.0.27
 * Generated at: 2012-12-10 20:52:07 UTC
 * Note: The last modified time of this file was set to
 *   the last modified time of the source file after
 *   generation to assist with modification tracking.
 */
package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;

public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {

  private static final javax.servlet.jsp.JspFactory _jspxFactory =
  javax.servlet.jsp.JspFactory.getDefaultFactory();

  private static java.util.Map
_jspx_dependants;

  private org.apache.jasper.runtime.TagHandlerPool
_005fjspx_005ftagPool_005fc_005fredirect_0026_005furl_005fnobody;

  private javax.el.ExpressionFactory _el_expressionfactory;
  private org.apache.tomcat.InstanceManager _jsp_instancemanager;

  public java.util.Map getDependants() {
return _jspx_dependants;
  }

  public void _jspInit() {
_005fjspx_005ftagPool_005fc_005fredirect_0026_005furl_005fnobody =
org.apache.jasper.runtime.TagHandlerPool.getTagHandlerPool(getServletConfig());
_el_expressionfactory =
_jspxFactory.getJspApplicationContext(getServletConfig().getServletContext()).getExpressionFactory();
_jsp_instancemanager =
org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(getServletConfig());
  }

  public void _jspDestroy() {
_005fjspx_005ftagPool_005fc_005fredirect_0026_005furl_005fnobody.release();
  }

  public void _jspService(final javax.servlet.http.HttpServletRequest
request, final javax.servlet.http.HttpServletResponse response)
throws java.io.IOException, javax.servlet.ServletException {

final javax.servlet.jsp.PageContext pageContext;
javax.servlet.http.HttpSession session = null;
final javax.servlet.ServletContext application;
final javax.servlet.ServletConfig config;
javax.servlet.jsp.JspWriter out = null;
final java.lang.Object page = this;
javax.servlet.jsp.JspWriter _jspx_out = null;
javax.servlet.jsp.PageContext _jspx_page_context = null;


try {
  response.setContentType("text/html;charset=UTF-8");
  pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
  _jspx_page_context = pageContext;
  application = pageContext.getServletContext();
  config = pageContext.getServletConfig();
  session = pageContext.getSession();
  out = pageContext.getOut();
  _jspx_out = out;

  out.write("\r\n");
  out.write("\r\n");
  out.write("\r\n");
  out.write("\r\n");
  if (_jspx_meth_c_005fredirect_005f0(_jspx_page_context))
return;
  out.write('\r');
  out.write('\n');
} catch (java.lang.Throwable t) {
  if (!(t instanceof javax.servlet.jsp.SkipPageException)

RE: NPE when starting up Embedded tomcat7

[Randy Toor]

Hi Chris,

The switch to the Tomcat class will be made soon enough, but for now it's 
really a time/risk thing at this stage of the project.  The Embedded class is 
ingrained pretty well and it isn't trivial to switch to use Tomcat.

Here is the code to set up the Embedded instance -


embedded = new Embedded();

embedded.setUseNaming(false);
embedded.setCatalinaHome(catalinaHome);
embedded.setCatalinaBase(catalinaBase);

engine = embedded.createEngine();
engine.setName(STANDARD_ENGINE_NAME);
// This name MUST match the name attributes of one of the Host elements
// nested immediately inside.
engine.setDefaultHost(defaultHostName);
engine.setParentClassLoader(classLoader);

host = embedded.createHost(defaultHostName, appBase);
// if not set: catalina/work/OSGiEngine/tomcatHost/_;
// ow: catalina//_
((StandardHost) host).setWorkDir(workDir);

host.setRealm(engine.getRealm());

// http-access log
((StandardHost) host).addValve(createLoggingValve());

engine.addChild(host);

File rootContext = new 
File(System.getProperty(SYS_PROPERTY_CATALINA_HOME) + SLASH + ROOT);
String docBase = "";
if (rootContext.exists()) {
docBase = rootContext.getAbsolutePath();
} else {
docBase = ROOT;
}
tomcatDefaultCtx = embedded.createContext("", docBase);
tomcatDefaultCtx.setSessionCookiePath("/");
tomcatDefaultCtx.addWelcomeFile(INDEX_JSP);
host.addChild(tomcatDefaultCtx);

embedded.addEngine(engine);


Actually, I did just try adding the line -

engine.setService(embedded);

Which does move me past the NPE (and on to a different error), but I'm not sure 
that this is what I want to do.  This code worked fine with tomcat6 and as I 
mentioned, the docs indicate a service need not be associated with an Engine.  
Is it a requirement now?



> Date: Tue, 11 Dec 2012 10:30:58 -0500
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: NPE when starting up Embedded tomcat7
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Randy,
> 
> On 12/10/12 6:09 PM, Randy Toor wrote:
> > I have an existing server which uses the Embedded class which I am 
> > tasked with upgrading to tomcat7 (deprecated, but we'll be keeping
> > it for the time being).
> 
> What part is deprecated? The Embedded class itself? Why not just
> switch-over to using the Tomcat class? It's much easier to use and now
> would be the time to make the switch.
> 
> > There were some small changes to the code to fix API breaks but
> > the startup stuff is the same.  When I start up the container I am
> > now seeing this -
> > 
> > INFO: Starting tomcat server 
> > org.apache.catalina.startup.Embedded||Dec 7, 2012 12:09:49 PM
> > org.apache.catalina.startup.Embedded startInternal INFO: Catalina
> > naming disabled Dec 7, 2012 12:09:49 PM
> > org.apache.catalina.core.StandardEngine startInternal INFO:
> > Starting Servlet Engine: Apache Tomcat/7.0.32 Dec 7, 2012 12:09:49
> > PM org.apache.catalina.util.LifecycleBase start INFO: The start()
> > method was called on component [Realm[NullRealm]] after start() had
> > already been called. The second call will be ignored. 
> > org.apache.catalina.util.LifecycleBase||Dec 7, 2012 12:09:49 PM
> > org.apache.catalina.util.LifecycleBase start Dec 7, 2012 12:09:49
> > PM org.apache.catalina.core.ContainerBase startInternal SEVERE: A
> > child container failed during start 
> > java.util.concurrent.ExecutionException:
> > org.apache.catalina.LifecycleException: Failed to start component
> > [StandardEngine[OSGiEngine].StandardHost[tomcathost].StandardContext[]]
> >
> > 
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> > at java.util.concurrent.FutureTask.get(FutureTask.java:83) at
> > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
> >
> > 
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:800)
> > at
> > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> >
> > 
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
> > at
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
> >
> > 
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:138) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >
> > 
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > at java.lang.Thread.run(Thread.java:743) Caused by:
> > org.apache.catalina.LifecycleException: Failed to start component
> > [StandardEngine[OSGiEngine].StandardHost[tomcathost].StandardContext[]]
> >
> > 
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:

Tomcat 7 Maven Plugin - set MaxPermSize

[David Miller]

I'm using the tomcat-maven plugin to set a value for MaxPermSize but it's
not working.

You can see in the below plugin my setting for JAVA_OPTS - I've also tried
MAVEN_OPTS and CATALINA_OPTS.

I can see that it's not working using jvisualvm (can also tell because my
app eventually craps out).

The only way that I can get an increase in perm gen size is to explicitly
set it like this:
MAVEN_OPTS="-XX:MaxPermSize=1024m"

Is it possible to use the tomcat-maven plugin to specify MaxPermSize size?

Thanks!


org.apache.tomcat.maven
tomcat7-maven-plugin
2.0


-XX:MaxPermSize=1024M

5

${project.build.directory}/${project.build.finalName}/META-INF/context.xml
/xyz



com.sun.faces
jsf-api
2.0.9


com.sun.faces
jsf-impl
2.0.9

Re: Revoked Certificate being accepted

[Will Nordmeyer]

On Tue, Dec 11, 2012 at 2:25 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Will,
>
> On 12/11/12 11:43 AM, Will Nordmeyer wrote:
>> I have my Tomcat 6.0.34 installation configured to use APR and
>> tcnative for certificate valiation & CRL checking.
>>
>> I have a revoked CRL and when I use the openssl command line to
>> check the certificate, it properly returns certificate revoked.
>
> You mean a revoked cert, right? I don't think you can revoke a CRL.
> (Would that un-revoke the certs in the list...?)
>
>> When I try going in through tomcat, however, it prompts for a
>> certificate to be selected and then once I select the revoked
>> certificate, it lets me into the application.
>
> Did you start the server, revoke the certificate, then attempt to use
> it to gain access? Tomcat loads the CRL once at startup when using
> JSSE, so I assume the same thing happens with the APR connector.
>
> If you restart Tomcat with no other changes, is the connection blocked?
>
>> ]# openssl verify -CApath /etc/ssl/certs -crl_check_all -verbose
>> -purpose sslclient TestThirtySeven_Revoked.pem
>> TestThirtySeven_Revoked.pem: C = US, O = , OU = OU1, OU = OU2,
>> OU = OU3, CN = TESTThirtySeven.REVOKED.950001 error 23 at 0
>> depth lookup:certificate revoked
>>
>> Connector info from Tomcat: > protocol="org.apache.coyote.http11.Http11AprProtocol"
>> SSLEnabled="true" scheme="https" maxHttpHeaderSize="8192"
>> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
>> enableLookups="false" acceptCount="100"
>> disableUploadTimeout="true" compression="on"
>> compressableMimeType="text/html,text/xml,text/plain,text/css,text/
>> javascript,application/xml,application/x-javascript,application/javascript"
>>
>>
> connectionTimeout="2"
>> secure="true" SSLCertificateFile="/etc/ssl/certs/servercrt01.crt"
>> SSLCertificateKeyFile="/etc/ssl/certs/serverkey.pem"
>> SSLPassword="password" SSLCACertificatePath="/etc/ssl/certs/"
>> SSLVerifyClient="require" SSLCARevocationPath="/etc/ssl/certs/"
>> sslProtocol="TLS" redirectPort="8443" />
>>
>> The log file shows nothing related to CRL.
>>
>> The /etc/ssl/certs directory has hash links to my CAs and CRLs.
>
> You mean symlinks?
>

>> Does it help if I hit the server with a baseball bat?
>
> If I'm right (above), and the baseball bat causes a reboot without any
> other damage, then it might actually help.
>
> I don't believe Tomcat has any current mechanism for refreshing the
> CRL. I think that's been requested once or twice... not sure if it's
> actually in Bugzilla. If it's not, it should be: care to look and file
> the enhancement request if necessary?
>
OK... hit me with the baseball bat - I forgot to restart tomcat.  I've
read those steps repeatedly and forgot when it was important.

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

Re: Revoked Certificate being accepted

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Will,

On 12/11/12 11:43 AM, Will Nordmeyer wrote:
> I have my Tomcat 6.0.34 installation configured to use APR and 
> tcnative for certificate valiation & CRL checking.
> 
> I have a revoked CRL and when I use the openssl command line to
> check the certificate, it properly returns certificate revoked.

You mean a revoked cert, right? I don't think you can revoke a CRL.
(Would that un-revoke the certs in the list...?)

> When I try going in through tomcat, however, it prompts for a 
> certificate to be selected and then once I select the revoked 
> certificate, it lets me into the application.

Did you start the server, revoke the certificate, then attempt to use
it to gain access? Tomcat loads the CRL once at startup when using
JSSE, so I assume the same thing happens with the APR connector.

If you restart Tomcat with no other changes, is the connection blocked?

> ]# openssl verify -CApath /etc/ssl/certs -crl_check_all -verbose 
> -purpose sslclient TestThirtySeven_Revoked.pem 
> TestThirtySeven_Revoked.pem: C = US, O = , OU = OU1, OU = OU2,
> OU = OU3, CN = TESTThirtySeven.REVOKED.950001 error 23 at 0
> depth lookup:certificate revoked
> 
> Connector info from Tomcat:  protocol="org.apache.coyote.http11.Http11AprProtocol" 
> SSLEnabled="true" scheme="https" maxHttpHeaderSize="8192" 
> maxThreads="150" minSpareThreads="25" maxSpareThreads="75" 
> enableLookups="false" acceptCount="100" 
> disableUploadTimeout="true" compression="on" 
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/ 
> javascript,application/xml,application/x-javascript,application/javascript"
>
> 
connectionTimeout="2"
> secure="true" SSLCertificateFile="/etc/ssl/certs/servercrt01.crt" 
> SSLCertificateKeyFile="/etc/ssl/certs/serverkey.pem" 
> SSLPassword="password" SSLCACertificatePath="/etc/ssl/certs/" 
> SSLVerifyClient="require" SSLCARevocationPath="/etc/ssl/certs/" 
> sslProtocol="TLS" redirectPort="8443" />
> 
> The log file shows nothing related to CRL.
> 
> The /etc/ssl/certs directory has hash links to my CAs and CRLs.

You mean symlinks?

> Does it help if I hit the server with a baseball bat?

If I'm right (above), and the baseball bat causes a reboot without any
other damage, then it might actually help.

I don't believe Tomcat has any current mechanism for refreshing the
CRL. I think that's been requested once or twice... not sure if it's
actually in Bugzilla. If it's not, it should be: care to look and file
the enhancement request if necessary?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHiMMACgkQ9CaO5/Lv0PBO/wCgu/sgriILftk5KTHdkHXxLs69
830AoL0e+7wF9XuaDvI3rZeHpT3KDH0E
=X1wp
-END PGP SIGNATURE-

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

Re: JMX with Listener

[Cédric Couralet]

>>> Okay.
 Now for my problems or questions: - Apparently, the Jmx
 listener listens on 0.0.0.0 (confirmed by a netstat) on the two
 ports configured for the listener, is it normal ? I thought
 that useLocalPorts would restrain the listening only to
 127.0.0.1.
>>>
>>> useLocalePorts /should/ force 127.0.0.1 (actually "localhost"...
>>> whatever that resolves to on your server). Can you confirm that
>>> you are editing the correct server.xml? If you edit it in one
>>> place and then deploy it, please make sure you have the latest
>>> version installed under CATALINA_BASE/conf.
>>>
>>
>> So it should force 127.0.0.1, ok !
>
> No, it forces the hostname "localhost". That might mean 10.0.0.1 on
> your system. Try "host localhost" and see what happens.

Yes, i should have thought of that sooner, I saw a couple of times a
windows server without any localhost in its host file.

thanks for the help.

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

Re: JMX with Listener

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cédric,

On 12/11/12 1:08 PM, Cédric Couralet wrote:
>> Okay.
>>> Now for my problems or questions: - Apparently, the Jmx
>>> listener listens on 0.0.0.0 (confirmed by a netstat) on the two
>>> ports configured for the listener, is it normal ? I thought
>>> that useLocalPorts would restrain the listening only to
>>> 127.0.0.1.
>> 
>> useLocalePorts /should/ force 127.0.0.1 (actually "localhost"... 
>> whatever that resolves to on your server). Can you confirm that
>> you are editing the correct server.xml? If you edit it in one
>> place and then deploy it, please make sure you have the latest
>> version installed under CATALINA_BASE/conf.
>> 
> 
> So it should force 127.0.0.1, ok !

No, it forces the hostname "localhost". That might mean 10.0.0.1 on
your system. Try "host localhost" and see what happens.

>>> - with jvisualvm i am able to connect through jmx with the url 
>>> service:jmx:rmi://localhost:10002/jndi/rmi://localhost:10001/jmxrmi
>>>
>>>
>>
>>> 
without entering the credentials (nagios:nagios).
>>> I thought that by entering 
>>> com.sun.management.jmxremote.authenticate=true, even read
>>> access would be restricted.
>> 
>> I think you need to double-check that you are actually using the 
>> configuration you think you are.
>> 
> 
> I think too now :) i'll double check it.
> 
> Is there a way to dump the jmx configuration in the jvm? It happens
> on all the tomcat in use (a lot) and i'm quite sure I am not
> mistaken the server.xml for every one of them.

You can see which ports are which using netstat. I don't believe you
can ask for the port numbers for your JMX listeners via JMX: you just
check the ports actually in use. You can check all the system
properties, of course, using jvisualvm.

> One question, though, in the tomcat doc (for 6.0.x) for the 
> JMXRemoteListener, the configuration is :
> 
> -Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/jmxremote.password
>
> 
-
-Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/jmxremote.access
> 
> while mine is
> -Dcom.sun.management.jmxremote.password.file=${CATALINA_BASE}/conf/jmxremote.password
>
> 
(notice the {} ).
> 
> is it my mistake?

As long as a bash-like shell is interpreting it, the {} will not
interfere: they are just an explicit notation to the shell where the
environment variable's name begins and ends.

>> Another note: using traditional JMX with Nagios is going to suck.
>> You are probably going to make, say, 5 connections to your server
>> every minute to check on things like heap size, request-time,
>> etc. Each of those connections requires a complete JMX connection
>> which is not cheap to make -- especially if the client is running
>> on the same server. That's 5 JVMs, 5 JMX connections, etc. every
>> minute (or 5 or whatever).
> 
> We don't really use nagios as is. We use check_MK, an agent
> installed on the  host for which i developped a plug in to get only
> the informations I want, with one connection to JMX (thus my need
> to restrict to localhost).

Gotcha. check_MK looks interesting, especially because you get RRD
databases for free. Hooray graphs!

>> If you just want to make some quick checks, consider looking at
>> the JMXProxyServlet which is provided by the manager webapp. I
>> believe it will be a much lighter-weight solution (and does not
>> require all of this crazy setup to configure JMX authentication,
>> etc.).
> 
> Some ancient rules force us to disactivate the manager webapp
> (those rules originated from some vulnerabilities with the manager
> webapp I believe), but i'm trying to get it back with the
> appropriate security, evebn if only to ease deployments :).

Note that you can enable access only to the JMXProxyServlet by simply
not allowing users to access other resources (like deploy/undeploy, etc.).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHeocACgkQ9CaO5/Lv0PDehgCfYgFICQgPH/NAhfWR2iorhCX0
s0oAniVmxG5lSUzPtNW5P9fSUYCZZiP0
=AdZM
-END PGP SIGNATURE-

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

Re: Question regarding OpenSSL Version used in TC 7.x

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Oliver,

On 12/11/12 12:14 PM, Oliver Zemann wrote:
> I would like to know if there is a list which version of TC
> (apr/native dll) was compiled against which version of openssl.

All three of tcnative, APR, and OpenSSL are shared libraries which
means that, barring static-linking or API compatibility, any version
of each should work with any version of any other. Of course, tcnative
requires certain minimum versions of both APR and OpenSSL at runtime,
and will complain if those are not available.

> I just noticed that my TC 7.0.23 is displaying openssl version
> 0.9.8h which has some known bugs. Its running on a win2k8 system
> installed as service.

What version of tcnative are you running? The win32 binary is not
packaged with Tomcat... only the tcnative source is included.

The current distribution of tcnative win32 binary (version 1.1.24) has
a file VERSIONS which recommends OpenSSL 1.0.1c, which appears to be
the version included with it (bin/openssl.exe).

Note that Tomcat 7.0.23 is kind of old. You should consider upgrading
both tcnative and Tomcat itself.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHeNIACgkQ9CaO5/Lv0PDTtACfTH2Vx5U134niZAaWltI+Y8tG
sOgAoLBQowYMqv0O5WYgE8O+OT2BiOog
=Pqpg
-END PGP SIGNATURE-

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

Re: JMX with Listener

[Cédric Couralet]

> Okay.
>> Now for my problems or questions: - Apparently, the Jmx listener
>> listens on 0.0.0.0 (confirmed by a netstat) on the two ports
>> configured for the listener, is it normal ? I thought that
>> useLocalPorts would restrain the listening only to 127.0.0.1.
>
> useLocalePorts /should/ force 127.0.0.1 (actually "localhost"...
> whatever that resolves to on your server). Can you confirm that you
> are editing the correct server.xml? If you edit it in one place and
> then deploy it, please make sure you have the latest version installed
> under CATALINA_BASE/conf.
>

So it should force 127.0.0.1, ok !

>> - with jvisualvm i am able to connect through jmx with the url
>> service:jmx:rmi://localhost:10002/jndi/rmi://localhost:10001/jmxrmi
>>
>>
> without entering the credentials (nagios:nagios).
>> I thought that by entering
>> com.sun.management.jmxremote.authenticate=true, even read access
>> would be restricted.
>
> I think you need to double-check that you are actually using the
> configuration you think you are.
>

I think too now :) i'll double check it.

Is there a way to dump the jmx configuration in the jvm?
It happens on all the tomcat in use (a lot) and i'm quite sure I am
not mistaken the server.xml for every one of them.

One question, though, in the tomcat doc (for 6.0.x) for the
JMXRemoteListener, the configuration is :

-Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/jmxremote.access

while mine is 
-Dcom.sun.management.jmxremote.password.file=${CATALINA_BASE}/conf/jmxremote.password
(notice the {} ).

is it my mistake?


> Another note: using traditional JMX with Nagios is going to suck. You
> are probably going to make, say, 5 connections to your server every
> minute to check on things like heap size, request-time, etc. Each of
> those connections requires a complete JMX connection which is not
> cheap to make -- especially if the client is running on the same
> server. That's 5 JVMs, 5 JMX connections, etc. every minute (or 5 or
> whatever).

We don't really use nagios as is. We use check_MK, an agent installed
on the  host for which i developped a plug in to get only the
informations I want, with one connection to JMX (thus my need to
restrict to localhost).


> If you just want to make some quick checks, consider looking at the
> JMXProxyServlet which is provided by the manager webapp. I believe it
> will be a much lighter-weight solution (and does not require all of
> this crazy setup to configure JMX authentication, etc.).

Some ancient rules force us to disactivate the manager webapp (those
rules originated from some vulnerabilities with the manager webapp I
believe), but i'm trying to get it back with the appropriate security,
evebn if only to ease deployments :).

Thanks for the help !

> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEAREIAAYFAlDHUKcACgkQ9CaO5/Lv0PCYVgCfdhcR80DY4nO1QTHCnohhBul8
> pmMAn0J1tFmswgyMAd4AXQBKyfNTMb1u
> =BzhT
> -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: Question regarding OpenSSL Version used in TC 7.x

[Mark Eggers]

On 12/11/2012 9:14 AM, Oliver Zemann wrote:

Hi,



I would like to know if there is a list which version of TC (apr/native dll)
was compiled against which version of openssl.

I just noticed that my TC 7.0.23 is displaying openssl version 0.9.8h which
has some known bugs. Its running on a win2k8 system installed as service.



Thanks in advance.



Oli




I don't know about a list, but I did a quick strings on 1.1.24 native, 
and it appears to have been built with OpenSSL 1.0.1c without FIPS.


7.0.29, 7.0.30, and 7.0.33 (all I have on this Windows 7 box) all run 
1.1.24 and OpenSSL 1.0.1c without FIPS.


Hope this helps a little bit.

. . . . just my (short) two cents
/mde/

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

Re: Why are Tomcat's threads more costly than background threads?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 12/11/12 11:16 AM, Mark Eggers wrote:
> On 12/11/2012 7:14 AM, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Julien,
>> 
>> Warning: this is long. Like, André-or-Mark-Eggers long.
>> 
> 
> Ouch (not really, thanks for the chuckle). Hemingway I am not,
> thorough I try to be.

Maybe more like Faulkner ;)

> Very nice explanation. This may be useful for managing some
> long-running financial calculations on a client's web site (and
> convince them to manage more server-side rather than Javascript /
> client side).

Honestly, anything that takes more than a few seconds should be
completely batched with an out-of-band notification. Just because you
can wrap an HTTP request/response around something doesn't mean you
should.

Further responses below.

>> So, a recap of throughput (req/sec) of the above 3
>> implementations:
>> 
>> Standard:  .15873 Background:.76923 Async:
>> 200.0
>> 
>> Using asynchronous dispatching can improve our throughput a huge 
>> number of times.
>> 
>> It's worth repeating what I said earlier: if your server can't 
>> actually handle this much load (200 emails per second, let's
>> say), then using asych isn't going to change anything. Honestly,
>> this trick only works when you have a lot of heterogeneous
>> requests. For example, maybe 10% of your traffic is handling
>> orders as implemented above, while the rest of your traffic is
>> for much smaller sub-500ms-requests.
> 
> I suppose you could just up the thread pool in Tomcat. However,
> sooner or later you're going to run out of resources somewhere.
> It's probably less expensive overall to use the asynchronous method
> than to dump more threads into an Executor thread pool.

Well, the point is that when you are "handing" requests faster
(because the work is really being done by another thread), you can
process a request queue faster with fewer threads. So, you don't have
to have a huge thread pool to handle a huge number of requests. You
probably still have to have the same number of threads (processors
versus real-workers) total in the JVM -- maybe even more -- but you
can process lighter-weight requests much more quickly if you don't
have to tie-up request processors all the time.

> Testing would be good.

Always.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHdaQACgkQ9CaO5/Lv0PB5eQCfY7oUomOapHW9wIZap0ovge0Z
HbwAoL2AclWKKS1qw3JxmHZv1/f3TosT
=xHaZ
-END PGP SIGNATURE-

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

Question regarding OpenSSL Version used in TC 7.x

[Oliver Zemann]

Hi, 

 

I would like to know if there is a list which version of TC (apr/native dll)
was compiled against which version of openssl. 

I just noticed that my TC 7.0.23 is displaying openssl version 0.9.8h which
has some known bugs. Its running on a win2k8 system installed as service. 

 

Thanks in advance.

 

Oli



smime.p7s
Description: S/MIME cryptographic signature

Revoked Certificate being accepted

[Will Nordmeyer]

I have my Tomcat 6.0.34 installation configured to use APR and
tcnative for certificate valiation & CRL checking.

I have a revoked CRL and when I use the openssl command line to check
the certificate, it properly returns certificate revoked.

When I try going in through tomcat, however, it prompts for a
certificate to be selected and then once I select the revoked
certificate, it lets me into the application.

]# openssl verify -CApath /etc/ssl/certs -crl_check_all -verbose
-purpose sslclient TestThirtySeven_Revoked.pem
TestThirtySeven_Revoked.pem: C = US, O = , OU = OU1, OU = OU2, OU
= OU3, CN = TESTThirtySeven.REVOKED.950001
error 23 at 0 depth lookup:certificate revoked

Connector info from Tomcat:


The log file shows nothing related to CRL.

The /etc/ssl/certs directory has hash links to my CAs and CRLs.

Does it help if I hit the server with a baseball bat?


--Will

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

Re: Why are Tomcat's threads more costly than background threads?

[Mark Eggers]

On 12/11/2012 7:14 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien,

Warning: this is long. Like, André-or-Mark-Eggers long.



Ouch (not really, thanks for the chuckle). Hemingway I am not, thorough 
I try to be.


Very nice explanation. This may be useful for managing some long-running 
financial calculations on a client's web site (and convince them to 
manage more server-side rather than Javascript / client side).



On 12/11/12 7:30 AM, Julien Martin wrote:

I am in reference to the following blog entry: Blog
entry



about Spring MVC 3.2 asynchronous support.


I understand Tomcat uses a thread pool in order to serve http/web
requests. Furthermore, the above article seems to indicate that
Spring MVC asynchronous support relieves Tomcat's thread pool and
allows for better concurrency in the webapp by using background
threads for "heavy-lift" operations.


I believe you are misinterpreting what that post has to say. It's not
that a "background" thread itself is more efficient, it's that
processing that does not need to communicate with the client can be
de-coupled from the request-processing thread-pool that exists for
that purpose.

An example - right from the blog post - will make much more sense than
what I wrote above. Let's take the example of sending an email
message. First, some assumptions:

1. Sending an email takes a long time (say, 5 seconds)
2. The client does not need confirmation that the email has been sent

If your were to write a "classic" servlet, it would look something
like this:

doPost() {
   validateOrder();

   queueOrder();

   sendOrderConfirmation(); // This is the email

   response.sendRedirect("/order_complete.jsp");
}

Let's say that validation takes 500ms, queuing takes 800ms, and
emailing (as above) takes 5000ms. That means that the request, from
the client perspective, takes 6300ms (6.3 sec). That's a noticeable delay.

Also, during that whole time, a single request-processing thread (from
Tomcat's thread pool) is tied-up, meaning that no other requests can
be processed by that same thread.

If you have a thread pool of size=1 (foolish, yet instructive), it
means you can only process a single transaction every 6.3 seconds.

Lets re-write the servlet with a background thread -- no
"asynchronous" stuff from the servlet API, but just with a simple
background thread:

doPost() {
   validateOrder();

   queueOrder();

   (new Thread() {
 public void run() {
   sendOrderConfirmation();
 }
   }).start();

   response.sendRedirect("order_complete.jsp");
}

So, now the email is being sent by a background thread: the response
returns to the client after 1.3 seconds which is a significant
improvement. Now, we can handle a request once every 1.3 seconds with
a request-processing thread-pool of size=1.

Note that a better implementation of the above would be to use a
thread pool for this sort of thing instead of creating a new thread
for every request. This is what Spring provides. It's not that Spring
can do a better job of thread management, it's that Tomcat's thread
pool is special: it's the only one that can actually dispatch client
requests. Off-loading onto another thread pool for background
processing means more client requests can be handled with a smaller
(or same-sized) pool.

Looking above, you might notice that the validateOrder() and
queueOrder() processes still take some time (1.3 seconds) to complete,
and there is no interaction with the client during that time -- the
client is just sitting there waiting for a response. Work is still
getting done on the server, of course, but there's no real reason that
the request-processing thread has to be the one doing that work: we
can delegate the entire thing to a background thread so the
request-processor thread can get back to dispatching new requests.

This is where servlet 3.0 async comes into play.

Let's re-write the servlet as an asynchronous one. I've never actually
written one, so I'm sure the details are going to be wrong, but the
idea is the same. This time, we'll do everything asynchronously.

doPost() {
   final AsyncContext ctx = request.startAsync();

   (new Thread() {
 public void run() {
   validateOrder();
   queueOrder();
   sendOrderConfirmation();

   ctx.getResponse().sendRedirect("/order_complete.jsp");

   ctx.complete();
 }
   }).start();
}

So, how what happens? When startAsync is called, an AsyncContext is
created and basically the request and response are packaged-up for
later use. The doPost method creates a new thread and starts it (or it
may start a few ms later), then returns from doPost. At this point,
the request-processor thread has only spent a few ms (let's say 5ms)
setting up the request and then it goes back into Tomcat's thread-pool
and can accept another request. Meanwhile, the "background" thread
will proce

Re: Why are Tomcat's threads more costly than background threads?

[Howard W. Smith, Jr.]

Wow, i'm reading this now, because I just experienced an issue on my
production server that is TomEE 1.5.1 (Tomcat 7.0.34), and the whole server
locked up all because I had a @Stateless EJB inserting data into multiple
tables in the database, because @Schedule timed event triggered the EJB to
check email server for incoming (customer) requests, and it literally took
down the server. I was on it as well as few other endusers, and then one
enduser captured a LOCK error and the screen capture (photo/pic) had an
error message that showed a long SQL query with datatable table and column
names t0..., t0...

What I primarily saw was the word 'lock' at the top of that, and we
definitely experienced a lockup. I'm about to check server logs and read
this article.

The @Stateless EJB had one transaction (entitymanager / persistence
context) that made database updates to multiple tables in the database. I
am only using entitymanager.persist(), flush(), and few lookups/queries
during that process.

But other endusers (including myself) could not do simple queries against
the database at all. Most of my queries contain query hints (readonly,
statement caching).

Also, I never seen this behavior at all, but this is first time I added
@Stateless EJB along with @Schedule that does database updates 'during
business hours'. I thought this would be a no-brainer, but I guess it's
not. Again, the server is TomEE 1.5.1 (tomcat 7.0.34).

Any advise, then please let me know. Onto reading this post now. Thanks. :)



On Tue, Dec 11, 2012 at 10:49 AM, Julien Martin  wrote:

> Thank you very much for this exhaustive reply Christopher.
>
> 2012/12/11 Christopher Schultz 
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Julien,
> >
> > Warning: this is long. Like, André-or-Mark-Eggers long.
> >
> > On 12/11/12 7:30 AM, Julien Martin wrote:
> > > I am in reference to the following blog entry: Blog
> > > entry<
> >
> http://blog.springsource.org/2012/05/06/spring-mvc-3-2-preview-introducing-servlet-3-async-support
> > >
> > >
> > >
> > about Spring MVC 3.2 asynchronous support.
> > >
> > > I understand Tomcat uses a thread pool in order to serve http/web
> > > requests. Furthermore, the above article seems to indicate that
> > > Spring MVC asynchronous support relieves Tomcat's thread pool and
> > > allows for better concurrency in the webapp by using background
> > > threads for "heavy-lift" operations.
> >
> > I believe you are misinterpreting what that post has to say. It's not
> > that a "background" thread itself is more efficient, it's that
> > processing that does not need to communicate with the client can be
> > de-coupled from the request-processing thread-pool that exists for
> > that purpose.
> >
> > An example - right from the blog post - will make much more sense than
> > what I wrote above. Let's take the example of sending an email
> > message. First, some assumptions:
> >
> > 1. Sending an email takes a long time (say, 5 seconds)
> > 2. The client does not need confirmation that the email has been sent
> >
> > If your were to write a "classic" servlet, it would look something
> > like this:
> >
> > doPost() {
> >   validateOrder();
> >
> >   queueOrder();
> >
> >   sendOrderConfirmation(); // This is the email
> >
> >   response.sendRedirect("/order_complete.jsp");
> > }
> >
> > Let's say that validation takes 500ms, queuing takes 800ms, and
> > emailing (as above) takes 5000ms. That means that the request, from
> > the client perspective, takes 6300ms (6.3 sec). That's a noticeable
> delay.
> >
> > Also, during that whole time, a single request-processing thread (from
> > Tomcat's thread pool) is tied-up, meaning that no other requests can
> > be processed by that same thread.
> >
> > If you have a thread pool of size=1 (foolish, yet instructive), it
> > means you can only process a single transaction every 6.3 seconds.
> >
> > Lets re-write the servlet with a background thread -- no
> > "asynchronous" stuff from the servlet API, but just with a simple
> > background thread:
> >
> > doPost() {
> >   validateOrder();
> >
> >   queueOrder();
> >
> >   (new Thread() {
> > public void run() {
> >   sendOrderConfirmation();
> > }
> >   }).start();
> >
> >   response.sendRedirect("order_complete.jsp");
> > }
> >
> > So, now the email is being sent by a background thread: the response
> > returns to the client after 1.3 seconds which is a significant
> > improvement. Now, we can handle a request once every 1.3 seconds with
> > a request-processing thread-pool of size=1.
> >
> > Note that a better implementation of the above would be to use a
> > thread pool for this sort of thing instead of creating a new thread
> > for every request. This is what Spring provides. It's not that Spring
> > can do a better job of thread management, it's that Tomcat's thread
> > pool is special: it's the only one that can actually dispatch client
> > requests. Off-loading onto another thread pool for background
> > pr

Re: Why are Tomcat's threads more costly than background threads?

[Julien Martin]

Thank you very much for this exhaustive reply Christopher.

2012/12/11 Christopher Schultz 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Julien,
>
> Warning: this is long. Like, André-or-Mark-Eggers long.
>
> On 12/11/12 7:30 AM, Julien Martin wrote:
> > I am in reference to the following blog entry: Blog
> > entry<
> http://blog.springsource.org/2012/05/06/spring-mvc-3-2-preview-introducing-servlet-3-async-support
> >
> >
> >
> about Spring MVC 3.2 asynchronous support.
> >
> > I understand Tomcat uses a thread pool in order to serve http/web
> > requests. Furthermore, the above article seems to indicate that
> > Spring MVC asynchronous support relieves Tomcat's thread pool and
> > allows for better concurrency in the webapp by using background
> > threads for "heavy-lift" operations.
>
> I believe you are misinterpreting what that post has to say. It's not
> that a "background" thread itself is more efficient, it's that
> processing that does not need to communicate with the client can be
> de-coupled from the request-processing thread-pool that exists for
> that purpose.
>
> An example - right from the blog post - will make much more sense than
> what I wrote above. Let's take the example of sending an email
> message. First, some assumptions:
>
> 1. Sending an email takes a long time (say, 5 seconds)
> 2. The client does not need confirmation that the email has been sent
>
> If your were to write a "classic" servlet, it would look something
> like this:
>
> doPost() {
>   validateOrder();
>
>   queueOrder();
>
>   sendOrderConfirmation(); // This is the email
>
>   response.sendRedirect("/order_complete.jsp");
> }
>
> Let's say that validation takes 500ms, queuing takes 800ms, and
> emailing (as above) takes 5000ms. That means that the request, from
> the client perspective, takes 6300ms (6.3 sec). That's a noticeable delay.
>
> Also, during that whole time, a single request-processing thread (from
> Tomcat's thread pool) is tied-up, meaning that no other requests can
> be processed by that same thread.
>
> If you have a thread pool of size=1 (foolish, yet instructive), it
> means you can only process a single transaction every 6.3 seconds.
>
> Lets re-write the servlet with a background thread -- no
> "asynchronous" stuff from the servlet API, but just with a simple
> background thread:
>
> doPost() {
>   validateOrder();
>
>   queueOrder();
>
>   (new Thread() {
> public void run() {
>   sendOrderConfirmation();
> }
>   }).start();
>
>   response.sendRedirect("order_complete.jsp");
> }
>
> So, now the email is being sent by a background thread: the response
> returns to the client after 1.3 seconds which is a significant
> improvement. Now, we can handle a request once every 1.3 seconds with
> a request-processing thread-pool of size=1.
>
> Note that a better implementation of the above would be to use a
> thread pool for this sort of thing instead of creating a new thread
> for every request. This is what Spring provides. It's not that Spring
> can do a better job of thread management, it's that Tomcat's thread
> pool is special: it's the only one that can actually dispatch client
> requests. Off-loading onto another thread pool for background
> processing means more client requests can be handled with a smaller
> (or same-sized) pool.
>
> Looking above, you might notice that the validateOrder() and
> queueOrder() processes still take some time (1.3 seconds) to complete,
> and there is no interaction with the client during that time -- the
> client is just sitting there waiting for a response. Work is still
> getting done on the server, of course, but there's no real reason that
> the request-processing thread has to be the one doing that work: we
> can delegate the entire thing to a background thread so the
> request-processor thread can get back to dispatching new requests.
>
> This is where servlet 3.0 async comes into play.
>
> Let's re-write the servlet as an asynchronous one. I've never actually
> written one, so I'm sure the details are going to be wrong, but the
> idea is the same. This time, we'll do everything asynchronously.
>
> doPost() {
>   final AsyncContext ctx = request.startAsync();
>
>   (new Thread() {
> public void run() {
>   validateOrder();
>   queueOrder();
>   sendOrderConfirmation();
>
>   ctx.getResponse().sendRedirect("/order_complete.jsp");
>
>   ctx.complete();
> }
>   }).start();
> }
>
> So, how what happens? When startAsync is called, an AsyncContext is
> created and basically the request and response are packaged-up for
> later use. The doPost method creates a new thread and starts it (or it
> may start a few ms later), then returns from doPost. At this point,
> the request-processor thread has only spent a few ms (let's say 5ms)
> setting up the request and then it goes back into Tomcat's thread-pool
> and can accept another request. Meanwhile, the "background" thread
> will process the actual transaction.
>
> Let

RE: JMX with Listener

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: JMX with Listener

> > Now for my problems or questions: - Apparently, the Jmx listener
> > listens on 0.0.0.0 (confirmed by a netstat) on the two ports
> > configured for the listener, is it normal ? I thought that
> > useLocalPorts would restrain the listening only to 127.0.0.1.

> useLocalePorts /should/ force 127.0.0.1 (actually "localhost"...
> whatever that resolves to on your server).

Which brings up the point that the hosts file might have an incorrect entry for 
"localhost" - that needs to be checked as well.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: NPE when starting up Embedded tomcat7

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randy,

On 12/10/12 6:09 PM, Randy Toor wrote:
> I have an existing server which uses the Embedded class which I am 
> tasked with upgrading to tomcat7 (deprecated, but we'll be keeping
> it for the time being).

What part is deprecated? The Embedded class itself? Why not just
switch-over to using the Tomcat class? It's much easier to use and now
would be the time to make the switch.

> There were some small changes to the code to fix API breaks but
> the startup stuff is the same.  When I start up the container I am
> now seeing this -
> 
> INFO: Starting tomcat server 
> org.apache.catalina.startup.Embedded||Dec 7, 2012 12:09:49 PM
> org.apache.catalina.startup.Embedded startInternal INFO: Catalina
> naming disabled Dec 7, 2012 12:09:49 PM
> org.apache.catalina.core.StandardEngine startInternal INFO:
> Starting Servlet Engine: Apache Tomcat/7.0.32 Dec 7, 2012 12:09:49
> PM org.apache.catalina.util.LifecycleBase start INFO: The start()
> method was called on component [Realm[NullRealm]] after start() had
> already been called. The second call will be ignored. 
> org.apache.catalina.util.LifecycleBase||Dec 7, 2012 12:09:49 PM
> org.apache.catalina.util.LifecycleBase start Dec 7, 2012 12:09:49
> PM org.apache.catalina.core.ContainerBase startInternal SEVERE: A
> child container failed during start 
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[OSGiEngine].StandardHost[tomcathost].StandardContext[]]
>
> 
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83) at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
>
> 
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:800)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>
> 
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
>
> 
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>
> 
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:743) Caused by:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[OSGiEngine].StandardHost[tomcathost].StandardContext[]]
>
> 
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
> ... 7 more Caused by: java.lang.NullPointerException: while trying
> to invoke the method org.apache.catalina.Service.findConnectors()
> of an object loaded from local variable 's' at
> org.apache.catalina.core.ApplicationContext.populateSessionTrackingModes(ApplicationContext.java:1191)
>
> 
at
org.apache.catalina.core.ApplicationContext.(ApplicationContext.java:125)
> at
> org.apache.catalina.core.StandardContext.getServletContext(StandardContext.java:2323)
>
> 
at
org.apache.catalina.core.StandardContext.postWorkDirectory(StandardContext.java:6062)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5102)
>
> 
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> ... 7 more org.apache.catalina.core.ContainerBase||Dec 7, 2012
> 12:09:49 PM org.apache.catalina.core.ContainerBase startInternal
> 
> 
> I looked into that particular line in ApplicationContext and I see
> this code is new in tomcat7 -
> 
> Service s = ((Engine)
> context.getParent().getParent()).getService(); Connector[]
> connectors = s.findConnectors();
> 
> 
> Looking at the API docs for Engine, it indicates that a Service
> does not necessarily need to be associated with an Engine (from the
> docs - "Set the Service with which we are associated (if any)". Am
> I missing a step now to prevent this? Or should there be a null
> check here?

Can your post your own code that uses the Embedded class? It will
probably be easier to spot a place where you've missed something
important (or have it out of order) than to just look at the stack
trace above and try to debug Tomcat in order to determine the original
mistake.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHUbIACgkQ9CaO5/Lv0PD+kQCfQ0i2evO0hn7g0E66MlpHpy4Q
jfsAnjOqNnKIHZRlK/zuDsr4VssZQVZR
=josl
-END PGP SIGNATURE-

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

Re: JMX with Listener

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cédric,

On 12/11/12 7:50 AM, Cédric Couralet wrote:
> In our tomcat, we use at the moment the JMXRemoteLifecycleListener 
> configured as :
> 
>  className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" 
> rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
> useLocalPorts="true" />

Okay.
> Now for my problems or questions: - Apparently, the Jmx listener
> listens on 0.0.0.0 (confirmed by a netstat) on the two ports
> configured for the listener, is it normal ? I thought that
> useLocalPorts would restrain the listening only to 127.0.0.1.

useLocalePorts /should/ force 127.0.0.1 (actually "localhost"...
whatever that resolves to on your server). Can you confirm that you
are editing the correct server.xml? If you edit it in one place and
then deploy it, please make sure you have the latest version installed
under CATALINA_BASE/conf.

> - with jvisualvm i am able to connect through jmx with the url 
> service:jmx:rmi://localhost:10002/jndi/rmi://localhost:10001/jmxrmi
>
> 
without entering the credentials (nagios:nagios).
> I thought that by entering 
> com.sun.management.jmxremote.authenticate=true, even read access
> would be restricted.

I think you need to double-check that you are actually using the
configuration you think you are.

Another note: using traditional JMX with Nagios is going to suck. You
are probably going to make, say, 5 connections to your server every
minute to check on things like heap size, request-time, etc. Each of
those connections requires a complete JMX connection which is not
cheap to make -- especially if the client is running on the same
server. That's 5 JVMs, 5 JMX connections, etc. every minute (or 5 or
whatever).

If you just want to make some quick checks, consider looking at the
JMXProxyServlet which is provided by the manager webapp. I believe it
will be a much lighter-weight solution (and does not require all of
this crazy setup to configure JMX authentication, etc.).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDHUKcACgkQ9CaO5/Lv0PCYVgCfdhcR80DY4nO1QTHCnohhBul8
pmMAn0J1tFmswgyMAd4AXQBKyfNTMb1u
=BzhT
-END PGP SIGNATURE-

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

Re: Why are Tomcat's threads more costly than background threads?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien,

Warning: this is long. Like, André-or-Mark-Eggers long.

On 12/11/12 7:30 AM, Julien Martin wrote:
> I am in reference to the following blog entry: Blog 
> entry
>
> 
about Spring MVC 3.2 asynchronous support.
> 
> I understand Tomcat uses a thread pool in order to serve http/web
> requests. Furthermore, the above article seems to indicate that
> Spring MVC asynchronous support relieves Tomcat's thread pool and
> allows for better concurrency in the webapp by using background
> threads for "heavy-lift" operations.

I believe you are misinterpreting what that post has to say. It's not
that a "background" thread itself is more efficient, it's that
processing that does not need to communicate with the client can be
de-coupled from the request-processing thread-pool that exists for
that purpose.

An example - right from the blog post - will make much more sense than
what I wrote above. Let's take the example of sending an email
message. First, some assumptions:

1. Sending an email takes a long time (say, 5 seconds)
2. The client does not need confirmation that the email has been sent

If your were to write a "classic" servlet, it would look something
like this:

doPost() {
  validateOrder();

  queueOrder();

  sendOrderConfirmation(); // This is the email

  response.sendRedirect("/order_complete.jsp");
}

Let's say that validation takes 500ms, queuing takes 800ms, and
emailing (as above) takes 5000ms. That means that the request, from
the client perspective, takes 6300ms (6.3 sec). That's a noticeable delay.

Also, during that whole time, a single request-processing thread (from
Tomcat's thread pool) is tied-up, meaning that no other requests can
be processed by that same thread.

If you have a thread pool of size=1 (foolish, yet instructive), it
means you can only process a single transaction every 6.3 seconds.

Lets re-write the servlet with a background thread -- no
"asynchronous" stuff from the servlet API, but just with a simple
background thread:

doPost() {
  validateOrder();

  queueOrder();

  (new Thread() {
public void run() {
  sendOrderConfirmation();
}
  }).start();

  response.sendRedirect("order_complete.jsp");
}

So, now the email is being sent by a background thread: the response
returns to the client after 1.3 seconds which is a significant
improvement. Now, we can handle a request once every 1.3 seconds with
a request-processing thread-pool of size=1.

Note that a better implementation of the above would be to use a
thread pool for this sort of thing instead of creating a new thread
for every request. This is what Spring provides. It's not that Spring
can do a better job of thread management, it's that Tomcat's thread
pool is special: it's the only one that can actually dispatch client
requests. Off-loading onto another thread pool for background
processing means more client requests can be handled with a smaller
(or same-sized) pool.

Looking above, you might notice that the validateOrder() and
queueOrder() processes still take some time (1.3 seconds) to complete,
and there is no interaction with the client during that time -- the
client is just sitting there waiting for a response. Work is still
getting done on the server, of course, but there's no real reason that
the request-processing thread has to be the one doing that work: we
can delegate the entire thing to a background thread so the
request-processor thread can get back to dispatching new requests.

This is where servlet 3.0 async comes into play.

Let's re-write the servlet as an asynchronous one. I've never actually
written one, so I'm sure the details are going to be wrong, but the
idea is the same. This time, we'll do everything asynchronously.

doPost() {
  final AsyncContext ctx = request.startAsync();

  (new Thread() {
public void run() {
  validateOrder();
  queueOrder();
  sendOrderConfirmation();

  ctx.getResponse().sendRedirect("/order_complete.jsp");

  ctx.complete();
}
  }).start();
}

So, how what happens? When startAsync is called, an AsyncContext is
created and basically the request and response are packaged-up for
later use. The doPost method creates a new thread and starts it (or it
may start a few ms later), then returns from doPost. At this point,
the request-processor thread has only spent a few ms (let's say 5ms)
setting up the request and then it goes back into Tomcat's thread-pool
and can accept another request. Meanwhile, the "background" thread
will process the actual transaction.

Let's assume that nothing in the run() method above interacts in any
way with the client. In the first example (no async), the client waits
the whole time for a response from the server, and the
request-processing thread does all the work. So, the client waits 6.3
seconds and the request-processing thread is "working" for 6.3 s

Re: Running Tomcat Behind Apache HTTP Server

[André Warnier]

Dhruva Reddy wrote:

Thanks, André, for your response.

To give you a little more context, I needed to get this working as soon as
possible, which I basically have.  Eventually, yes, I want the static
content to be served by HTTPD, and the dynamic content to be served by
Tomcat.  I did not want to deploy my application as ROOT, for reasons that,
now that I think about it, don't really make sense.

Anyway, your clue about the Directory directive was very helpful.  It
turned out that my rewrite rules were being ignored.  I ended up with two
rules, each on the condition that the request URI does not already contain
the context.  I settled on the following (I'm running a Grails application
which automagically recognizes the "html" extension):

RewriteEngine On
RewriteCond $0 !^/application/(.*)
RewriteRule ^(.*)/$ ajp://localhost:8009/application/$1 [P]
RewriteCond $0 !^/application/(.*)
RewriteRule ^(.*)\.html$ ajp://localhost:8009/application$1.html [P]

I know I still have some work to do, but at least I now have it basically
working.

Good if it works. You did not originally specify which Apache-Tomcat connector you were 
using, so I took a potshot and guessed mod_jk, wrongly.


About the rules above :
- what happens when the URL already starts with "/application" ?
- the capture part in the RewriteCond above does not seem to be necessary, as you are 
testing for a "not match", so whatever is captured wouldn't be useful anyway.

- what happens when the Tomcat webapp returns a redirect ?
  Do you have some ProxyPassReverse directive for that ?

If I may comment, I believe that by forwarding "/" to tomcat's "/application", and 
afterward having other sub-sections of "/" not being forwarded to Tomcat, you are setting 
yourself up for a lot of complications later on.
A lot of directive's effects in Apache are "inherited" from a top location to 
sub-locations by default, and you are going to find yourself obliged to countermand this 
inheritance in each sub-section. When you start mixing this with the relative paths that 
tomcat will generate for embedded images etc, and with (maybe) authentication and 
access-control, you'll be in for a treat.
If you are just starting this website's setup, it may be better to pause and think of a 
simpler layout.

Just my two cent.


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

Re: I can only access Tomcat 7 when running via console (startup.bat)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yuri,

On 12/10/12 11:22 PM, Yuri E wrote:
> 2012/12/10 Daniel Mikusa 
> 
>> On Dec 10, 2012, at 11:28 AM, André Warnier wrote:
>> 
>>> Yuri E wrote:
 2012/12/7 André Warnier 
> Christopher Schultz wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> André,
>> 
>> On 12/7/12 1:55 PM, André Warnier wrote:
>> 
>>> I am relatively familiar with tomcat under Windows,
>>> and if your explanations of what works and what
>>> doesn't above are exact, then I don't know either.
>>> 
>> One possibility: during the installation, the user chose 
>> to bind only to localhost instead of 0.0.0.0.
>> 
> Aaaah. Yes, and that choice probably only exists in the 
> Service
>> installer.
> That would fit. And he would see that with netstat.
> 
>> 
 "netstat -abn" results: -- running Tomcat on console: TCP 
 0.0.0.0:8009   0.0.0.0:0  LISTENING
>> 3844
 [java.exe] TCP0.0.0.0:8080   0.0.0.0:0 LISTENING
>> 3844
 [java.exe] TCP127.0.0.1:8005 0.0.0.0:0 LISTENING
>> 3844
 [java.exe] -- running Tomcat as Service: TCP0.0.0.0:8009 
 0.0.0.0:0  LISTENING
>> 488
 [Tomcat7.exe] TCP0.0.0.0:8080   0.0.0.0:0 
 LISTENING
>> 488
 [Tomcat7.exe] TCP127.0.0.1:8005 0.0.0.0:0 
 LISTENING
>> 488
 [Tomcat7.exe]
>>> 
>>> Well, Chris, that was a worthy guess, but apparently it is not 
>>> the
>> reason here.
>>> 
>>> Didactic section :
>>> 
>>> In both cases above (running in a console window and running
>>> as a
>> Service), we have Tomcat listening :
>>> - on port 8080, all interfaces, all IP addresses.  That's the 
>>> HTTP
>> Connector
>>> (see in server.xml) - on port 8009, all interfaces, all IP 
>>> addresses.  That's the AJP
>> Connector
>>> (see in server.xml) (and maybe you don't need that one, and 
>>> can
>> comment it out)
>>> - on port 8005, only on the "localhost" address.  That is the 
>>> "shutdown
>> port", which is limited to listening for calls originating from 
>> the same physical host, for security reasons (so that nobody can 
>> shut down your Tomcat from the internet e.g.)
>>> 
>>> And the reason why in one case the process is "Tomcat7.exe"
>>> and in the
>> other case it is "java.exe" :
>>> - when Tomcat runs as a Service, there is a "service wrapper" 
>>> involved,
>> which "wraps around" the java process (and Tomcat in it), and 
>> which provides the special functions that Windows Services must 
>> provide for Windows (like listening to Windows "star/stop 
>> service" messages etc..). This wrapper is a copy of the 
>> procrun.exe program, renamed to "tomcat7.exe" for convenience.
>>> So when you run Tomcat as a Service, Windows really starts
>> "tomcat7.exe", and tomcat7.exe runs java.exe which runs tomcat.
>>> 
>>> -- end of didactic section --
>>> 
>>> 
>>> To summarise what is happening now :
>>> 
>>> 1) Tomcat running in a console window : a) can be accessed
>>> from a browser running on the same machine b) can be accessed
>>> from a browser running on another machine
>>> 
>>> 2) Tomcat running as a Windows Service : a) can be accessed 
>>> from a browser running on the same machine b) but cannot be 
>>> accessed from a browser running on another machine
>>> 
>>> while in both cases it is listening to 0.0.0.0:8080
>>> 
>>> It it was a DNS issue, then both 1-b and 2-b wouldn't work.
>>> But only 2-b
>> doesn't work.
>>> If it was a firewall issue or similar, we'd have the same. If 
>>> it was an issue of the java parameters or others used when 
>>> starting
>> tomcat as a service, then both 2-a and 2-b would not work. But 
>> 2-a works.
>>> 
>>> Some weird MS security rule, applying to services but not to 
>>> regular
>> processes ?
>>> 
>>> Yuri, can you repeat for us which exact URL's you are using to 
>>> access
>> Tomcat, in each of the cases above ?
>>> 
>>> 1-a : 1-b : 2-a : 2-b :
>>> 
>>> and how the problem shows up, when "it does not work" ?
>> 
>> Also, if you have a firewall running on the server, how is it 
>> configured? Do you have a rule to allow tcp on port 8080?  I ask 
>> because some firewalls will restrict at the application level as 
>> well as the port level. For example, only "java.exe" is allowed 
>> to listen on port 8080.
>> 
>> Dan
>> 
>> 
>>> 
>>> 
>>> -
>>>
>>>
>>> 
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
>> 
>> 
> I couldn't access your answers at work today. Then I decided to 
> make the tests at home. I installed Tomcat exactly as the same 
> manner as I

Re: Tomcat 7.33 update on Windows

[Konstantin Kolinko]

2012/12/11 Justin Larose :
> I just updated Tomcat 7 from version 7.11 to 7.33 on my windows server but
> when I goto the URL I am seeing 500 error, "Cannot load JDBC driver class
> 'com.microsoft.sqlserver.jdbc.SQLServerDriver'"
> Not sure why. I made a copy of all config directories prior to install and
> copied them all to the new Tomcat home. Below is the full stack.
>
> (...)
>
> root cause
>
> java.lang.ClassNotFoundException:
> com.microsoft.sqlserver.jdbc.SQLServerDriver
>

What jar contains the above class and whether it is present in your
installation? I guess you forgot to copy it.

(It should be placed into Tomcat's lib/ directory).

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

Tomcat 7.33 update on Windows

[Justin Larose]

I just updated Tomcat 7 from version 7.11 to 7.33 on my windows server but 
when I goto the URL I am seeing 500 error, "Cannot load JDBC driver class 
'com.microsoft.sqlserver.jdbc.SQLServerDriver'"
Not sure why. I made a copy of all config directories prior to install and 
copied them all to the new Tomcat home. Below is the full stack.

_

HTTP Status 500 - javax.servlet.ServletException: 
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver 
class 'com.microsoft.sqlserver.jdbc.SQLServerDriver'



type Exception report

message javax.servlet.ServletException: 
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver 
class 'com.microsoft.sqlserver.jdbc.SQLServerDriver'

description The server encountered an internal error that prevented it 
from fulfilling this request.

exception 

org.apache.jasper.JasperException: javax.servlet.ServletException: 
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver 
class 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
 
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:549)
 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:455)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)


root cause 

javax.servlet.ServletException: 
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver 
class 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
 
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:912)
 
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:841)
org.apache.jsp.index_jsp._jspService(index_jsp.java:286)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)


root cause 

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot load JDBC driver 
class 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1429)
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1371)
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
 com.compasseng.jsp.client.cors.Scanner.getScanners(Scanner.java:156)
org.apache.jsp.index_jsp._jspService(index_jsp.java:151)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)


root cause 

java.lang.ClassNotFoundException: 
com.microsoft.sqlserver.jdbc.SQLServerDriver
 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1420)
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1371)
 
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
 com.compasseng.jsp.client.cors.Scanner.getScanners(Scanner.java:156)
org.apache.jsp.index_jsp._jspService(index_jsp.java:151)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)


note The full stack trace of the root cause is available in the Apache 
Tomcat/7.0.33 logs.




Apache Tomcat/7.0.33

Thanks,
Justin
**
This email and any files transmitted with it are intended solely for 
the use of the individual or agency to whom they are addressed. 
If you have received this email in error please notify the Navy 
Exchange Service Comm

Re: CATALINA_OPTS under windows 7

[Daniel Mikusa]

On Dec 10, 2012, at 6:14 PM, Raf Roger wrote:

> Hi,
> 
> i need to setup CATALINA_OPTS environment variable under windows 7.
> I read that in directory *tomcatDir/bin/* should be a file named setenv.bat
> for Windows in which i could define the  CATALINA_OPTS environment variable.
> 
> However after a fresh installation of Tomcat 7.0.33 i discovered that such
> file doesn't exist.
> is it normal ?

This is normal and intentional.

> 
> can i just create it ?

Yes, you should create the file.  

> what should i take care to make it correctly ?

You can use any text editor to create the file.  Make sure that it is 
syntactically a valid Window batch script.  Most of the time, you would just 
set environment variables in this file.  

For example:

  set JAVA_HOME=C:\path\to\java\home
  set CATALINA_OPTS=-Xmx2G -Xss256k

As a note, you only want to use the setenv.bat file if you are running Tomcat 
from the console (something that is done rarely).  In most  cases, you'll be 
running as a Windows Service.  If you are running as a Windows Service then you 
don't want to use setenv.bat.  Instead, you'll want to use the Tomcat GUI 
application to make configuration changes.

  
https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html#Tomcat7w_monitor_application
  https://wiki.apache.org/tomcat/FAQ/Windows#Q11

Dan


> thx.
> 
> -- 
> Alain
> ---
> Windows 7 x64 / Fedora 17 x64
> MySQL 5.5.28
> Apache 2.4.3 / OpenSSL 1.0.1c
> Tomcat 7.17
> PHP 5.4.8


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

Re: Running Tomcat Behind Apache HTTP Server

[Dhruva Reddy]

Thanks, André, for your response.

To give you a little more context, I needed to get this working as soon as
possible, which I basically have.  Eventually, yes, I want the static
content to be served by HTTPD, and the dynamic content to be served by
Tomcat.  I did not want to deploy my application as ROOT, for reasons that,
now that I think about it, don't really make sense.

Anyway, your clue about the Directory directive was very helpful.  It
turned out that my rewrite rules were being ignored.  I ended up with two
rules, each on the condition that the request URI does not already contain
the context.  I settled on the following (I'm running a Grails application
which automagically recognizes the "html" extension):

RewriteEngine On
RewriteCond $0 !^/application/(.*)
RewriteRule ^(.*)/$ ajp://localhost:8009/application/$1 [P]
RewriteCond $0 !^/application/(.*)
RewriteRule ^(.*)\.html$ ajp://localhost:8009/application$1.html [P]

I know I still have some work to do, but at least I now have it basically
working.


On Mon, Dec 10, 2012 at 5:43 PM, André Warnier  wrote:

> Jeff Beard wrote:
>
>> On Mon, Dec 10, 2012 at 2:22 PM, Dhruva Reddy  wrote:
>>
>>  Hello,
>>>
>>> I have a question about running Tomcat behind Apache HTTP server.  I hope
>>> this is not inappropriate for this list.
>>>
>>> I am running a website on Tomcat 7.0.33, behind Apache 2.2.15, on CentOS
>>> 6.3 (using Tomcat connector 1.2.37).  I would like the user to go to our
>>> base URL (http://www.example.com), but have the request served by a web
>>> application running on Tomcat (I have the connector working, so that you
>>> can access the application through 
>>> http://www.example.com/**application/
>>> ).
>>>
>>> I thought this could be accomplished through a rewrite rule on the HTTP
>>> server, but I can't seem to get it to work, nor can I find much
>>> information
>>> on it.  I can't really find any best practices around this, either.  Has
>>> anyone done this successfully?
>>>
>>> I have tried many things, but this is what I currently have in
>>> httpd.conf:
>>>
>>> 
>>> Options Indexes FollowSymLinks
>>> AllowOverride None
>>> Order allow,deny
>>> Allow from all
>>> RewriteEngine On
>>> 
>>> RewriteBase /
>>> RewriteRule ^/ application/ [NC]
>>> RewriteLog "/etc/httpd/logs/rewrite.log"
>>> RewriteLogLevel 9
>>> 
>>> 
>>>
>>> I did confirm that the rewrite module is loaded.  Any insights would be
>>> greatly appreciated.
>>>
>>> Thanks,
>>> Dhruva
>>>
>>>
>>
>> Dhruva,
>>
>> Based on the snippet of configuration you've provided it isn't clear that
>> you've configured the Tomcat Connector. Perhaps there's more that you
>> haven't shown us? Anyway, most recently I've configured Apache much like
>> this document describes:
>>
>> http://tomcat.apache.org/**connectors-doc/generic_howto/**quick.html
>>
>>
>>
> I have another couple of questions :
> 1) considering that you want that "^/" (the top of your Apache httpd's URL
> space) be forwarded to Tomcat, do you have anything that would /not/ be
> forwarded to Tomcat ?
> If yes, where would that part live (in which directory/URL space of your
> httpd server) ?
> If no, why do you even need the front-end Apache httpd ?
> 2) have you considered making your Tomcat application "/application" be
> the "/ROOT" default webapp of Tomcat ? Then it would be mapped to the path
> "/" in Tomcat also, and no rewriting would be required.
>
> But, assuming for now that you need a front-end httpd and that you want to
> forward everything to "/application" in Tomcat, do this instead :
>
> RewriteEngine On
> RewriteLog "/etc/httpd/logs/rewrite.log"
> RewriteLogLevel 9
>
> 
>
>  Order allow,deny
>  Allow from all
>  RewriteRule (.*) /application/$1 [NC]
>  SetHandler jakarta-servlet<-- this is what forwards to Tomcat
> 
>
> Explaining all the changes in detail would be a lot here, but here's a few
> notes :
> 1) SetHandler jakarta-servlet : replaces "JkMount" instructions, with
> similar effect. It tells Apache that for this, you want mod_jk (the
> Apache-Tomcat connector) to generate the response, which it does by
> forwarding the request to tomcat, and collecting tomcat's response.
> 2) removal of  directives : you don't want them here, I guess.
> If mod_rewrite is not there, none of your Rewrite directives will be
> understood, and your Apache won't start. That is probably what you really
> want; you don't just want Apache to do something else then.
> 3) you can move the 3 first Rewrite* directives back into the 
> section if you want.  But where they are, they will be inherited by it
> anyway.
> 4) I think (I am not 100% sure) that using a  section for this
> is already "a bit late" in the Apache cycle.  By the time Apache looks
> inside a  section, it has already parsed the URL, and mapped it
> to a disk directory. In

JMX with Listener

[Cédric Couralet]

Hello,

In our tomcat, we use at the moment the JMXRemoteLifecycleListener
configured as :



The configuration for the windows service is :

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=${CATALINA_BASE}/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=${CATALINA_BASE}/conf/jmxremote.access
-Dcom.sun.management.jmxremote.ssl=false

with jmxremote.access being a textfile with:

nagios readonly

and jmxremote.password :

nagios nagios

Version and OS information :
 - Tomcat 6.0.35
 - Windows server 2003 32bit
 - jdk 1.6.36

Now for my problems or questions:
 - Apparently, the Jmx listener listens on 0.0.0.0 (confirmed by a
netstat) on the two ports configured for the listener, is it normal ?
I thought that useLocalPorts would restrain the listening only to
127.0.0.1.
As i can't seem to connect on that ports with a remote host, I think
it is normal but I would like some clarifications if possible.

 - with jvisualvm i am able to connect through jmx with the url
service:jmx:rmi://localhost:10002/jndi/rmi://localhost:10001/jmxrmi
without entering the credentials (nagios:nagios).
I thought that by entering
com.sun.management.jmxremote.authenticate=true, even read access would
be restricted.

Thank you for any answers.

Cédric Couralet

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

Why are Tomcat's threads more costly than background threads?

[Julien Martin]

Hello,

I am in reference to the following blog entry: Blog
entry
about Spring MVC 3.2 asynchronous support.

I understand Tomcat uses a thread pool in order to serve http/web requests.
Furthermore, the above article seems to indicate that Spring MVC
asynchronous support relieves Tomcat's thread pool and allows for better
concurrency in the webapp by using background threads for "heavy-lift"
operations.

Can anyone please provide informed advice as to why that is? Why is a
"front-end" thread taken from the tomcat thread pool more costly than a
background thread?

Regards,

J.

http://blog.springsource.org/2012/05/06/spring-mvc-3-2-preview-introducing-servlet-3-async-support/