[ANN] Apache Tomcat 7.0.23 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.23

This release includes numerous bug fixes and several new features
compared to version 7.0.22. The notable new features include:
* The ability to start and stop child containers (primarily Contexts:
  i.e. web applications) in parallel which can significantly improve
  start times. This is disabled by default but can be enabled by
  setting the startStopThreads attribute of a Host to a value greater
  than one.
* Cache the results of parsing the global and host level context.xml
  files to improve start times.
* Improve the handling of failed deployments so that a broken
  application can be fixed (e.g. via JMX) and another attempt made to
  start it rather than it having to be removed.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note that this version has 4 zip binaries: a generic one and three
bundled with Tomcat native binaries for Windows operating systems
running on different CPU architectures.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guide from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team





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

Re: System.out is not going to catalina.out

[Mark Thomas]

On 27/11/2011 18:29, Chris Moore wrote:
>  
> 
> I'm new to using tomcat.  I've done some developing with Google App Engine,
> but I'm looking to
> 
> host something on my own system instead of theirs.
> 
>  
> 
> My system is running Ubuntu 10.04.3.  Tomcat is 6.0.24, JVM is 1.6.0_20-b20.
> 
>  
> 
> I've written my app using GWT 2.4.0.  I'm also trying to use Hibernate and
> MySQL for the back end.
> 
> This is my first time with Hibernate as well, so I'm still coming up to
> speed with getting that configured
> 
> and working.
> 
>  
> 
> I can run my application in dev mode under Eclipse, with Hibernate
> configured to connect to the mysql
> 
> server, and it works fine.  But when host the application under Tomcat on
> the server it doesn't actually
> 
> update the database.  It seems to work, I get no errors or stack traces, but
> the data never gets updated.
> 
>  
> 
> That leads to the real question I'm asking for help with - I can't seem to
> get any kind of logging to work,
> 
> including simply writing to System.out.  All the documentation I can find
> says that System.out should get
> 
> written to catalina.out, but I'm not seeing it.   I do see "deploying" and
> "undeploying" messages in
> 
> catalina.out, so I know I've got the right file and it is getting logged to,
> but I don't see anything else there.
> 
>  
> 
> I've tried changing logging.properties to specify level=ALL for everything,
> thinking maybe the output was
> 
> getting filtered, but that didn't help.
> 
>  
> 
> Can anyone suggest what I might be doing wrong?  Is my System.out going
> somewhere else?  
> 
>  
> 
> I'm generally pretty good at working out problems for myself, but with no
> error messages and no way to 
> 
> get any kind of logging I'm stuck.  If someone could help me at least get
> logging working I can probably
> 
> work the rest out.

Start with a clean Tomcat 7.0.23 install and a simple JSP that writes to
stdout.

Also, check all the other log files.

Mark

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

Re: Tomcat user roles

[Mark Thomas]

On 29/11/2011 17:05, Christopher Schultz wrote:
> Mark,
> 
> On 11/29/11 11:15 AM, ma...@apache.org wrote:
>> Christopher Schultz  wrote:
> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> Bill,
>>> 
>>> On 11/28/11 7:08 PM, Bill Wang wrote:
>>>> Here I have the last question, what's the reload option, is
>>>> it same as stop/start?
>>> 
>>> According to markt (who is known to be occasionally 
>>> trustworthy):
>>> 
>>> reload = stop + start
> 
>> I'm pretty sure I didn't say that.
> 
> Sorry, you said:
> 
> On 11/25/11 12:47 PM, Mark Thomas wrote:
>> There is no such command as restart. You'll need: 
>> /html/stop 
>> /html/start
> 
> I drew my own (perhaps incorrect) conclusion from that.

In short:
reload != restart

Fuller explanation below. There is a subtle but important difference.

Mark

>> Reload keeps the same Context object (and doesn't reread the 
>> Context config) but does re-read web.xml and allows Jars to be 
>> updated.
> 
>> Stop/start creates a new Context object (as well as re-reading 
>> web.xml) and is therefore is a full restart of the context.
>> Reload is sort of half a restart. There is no single command
>> equivalent to stop/start.
> 
> Gotcha.
> 
> -chris
> 
> -
>
> 
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: Tomcat-7.0.23 startup deadlocks

[Mark Thomas]

On 29/11/2011 19:27, Zampani, Michael wrote:
>> I think you are right. When no realm is configured in server.xml and in the
>> context of a webapp, StandardEngine tries to set a default realm.
>> That is guarded by a lock, which is held by the main thread.
>>
>> To work around this problem, you can define a simple realm inside the
>> context of your webapp or globally in server.xml.
>>
>> To fix the problem we will have to look at the locking for setRealm in
>> ContainerBase.
>>
>> Regards
>>   Felix
> 
> I can confirm that reverting CLN 1190190
> http://svn.apache.org/viewvc?view=revision&revision=1190190
> fixes this.
> 
> Alternatively, removing the synchronized block from setRealm() also 'fixes' 
> this.
> It looks like we can add some locks around Realm,

That fix has just been applied to trunk and will be back-ported shortly.

> but it doesn't look like ContainerBase is even close to being actually 
> threadsafe.

Agreed.

> I'm not sure what the existing standards for Tomcat code are in this area.

That is a grey area. Generally, we avoid making code thread safe unless
we have to. The ContainerBase and related code generally doesn't need to
be thread safe as there is only ever one thread working with that code.
The threaded deployment doesn't really change that. Where thread safety
does come in is when we consider on-the-fly updating e.g. via JMX while
the component is in the STARTED state. Generally, we look at those
issues on a case-by-case basis and where there is a good case for
on-the-fly updates, we make it thread safe, where there isn't we make it
read-only. One of the parts of the GSOC project that looked at JMX a few
years ago was meant to review all attributes for thread-safety (and
expected to make most of them read-only). Unfortunately, that project
didn't make much progress.

Mark

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

Re: Problems with forwaring HTTP to HTTPS

[Mark Thomas]

On 30/11/2011 18:32, Gregor S. wrote:
> My understanding was, that in the global web.xml
> ($catalina.home/conf/web.xml) the defaults are specified and promoted
> to all webapps. But it seems as the webapp doesn't inherit the element
>  from the global web.xml if it specifies it's
> own  - my expectation was, that it inherits
> those elements not specified inside the webapp's
> deployment-descriptor.

Your understanding is wrong.

You need to read the 2.5 servlet specification, particularly section
SRV.12.7.1.

Mark

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

Re: Tomcat 7 + exception while adding cookies

[Mark Thomas]

On 01/12/2011 15:49, Martin Kuen wrote:
> I first blamed eclipse wtp doing sth. wrong when applying the
> configuration. Therefore, I checked the connector's jmx properties and to
> my surprise I could no longer find a property called "maxHttpHeaderSize"
> for the connector (comparing tc 6 to 7).

The JMX properties are not the definitive list of supported properties.
That is provided by the documentation and maxHttpHeaderSize is still listed.

> Was it dropped by intention? I skimmed through the changelogs but couldn't
> find an explanation . . .

It was dropped from JMX as part of the GSOC attribute clean-up since
that attribute is implemented in the ProtocolHandler (where it is
available via JMX).

> Afaik as I know this is a configurable setting for (at least most)
> webservers

As it is (or should be if it is working properly) for all version of Tomcat.

Mark

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

Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?

[Mark Thomas]

On 01/12/2011 18:17, oh...@cox.net wrote:
> Having said all of that, I guess that my question has changed
> somewhat.  Specifically, now I'm wondering:  With what I described
> above, and with my valve as described above, does the asserted user
> NOT have to be in the Tomcat realm at all?

Correct. If you populate the user Principal, Tomcat doesn't care whether
or not it is in the Realm.

Mark

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

Re: Tomcat filter-mapping dispatcher forward

[Mark Thomas]

On 05/12/2011 14:45, Hodchenkov, Paul wrote:
> Hi all,
> I am trying to configure dispatcher forward rule for filter in tomcat 7.0.22
>
> UrlRewriteFilter
> /*
> REQUEST
> FORWARD
> 

That looks right at first glance.

> However, tomcat ignores dispatcher definition and does not fill dispatchers 
> in org.apache.catalina.deploy.FilterMap (used debug) , so it always returns 
> REQUEST in getDispatcherMapping.

Hmm. Odd. This is tested by the TCK that every Tomcat release must pass
so I don't think there is a bug - or if there is it is an odd edge case.

I'd suggest that the way forward is to write the simplest possible test
case (1 * JSP + 1 * Servlet + web.xml should be plenty) that
demonstrates this issue. If you still see the issue with that test case,
it will probably be time to open a bug.

Mark

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

Re: Any servlet API event to denote change in session id

[Mark Thomas]

On 07/12/2011 17:04, Jess Holle wrote:
> I note that in recent versions of Tomcat (e.g. 7.0.23), the session id
> changes when you do a form-based authentication.
> 
> I do not see any sort of notice via anything one can listen to via the
> servlet API to receive notice of this change.
> 
> This makes things rather ugly if one is monitoring the sessions oneself
> -- as their identity changes out from under you without any notice.
> 
> Am I missing something here?  [Yes, I note the container event, but that
> necessitates Tomcat-specific code, etc -- especially given that this
> isn't fired as a JMX notification anywhere that I can see.]

No, you aren't missing anything.

Note the session object does not change, just the value returned for the ID.

This will hopefully get fixed in Servlet 3.1

Your other option is to turn off the session fixation protection (not
recommended).

Mark

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

Re: "VerifyError: ... Illegal constant pool index" when jspx invokes a tagx on Tomcat 7.0.16

[Mark Thomas]

On 08/12/2011 14:19, Robert Winch wrote:
> On Thu, Dec 8, 2011 at 4:29 AM, Pid  wrote:
>> You say below that the compiled tags & JSP don't appear to have been
>> recompiled - either upgrade, or clear the work directory to ensure that
>> they have been.
>>
> 
> I'm not sure I understand. Is there a reason we would want them to be
> recompiled? The reason I had mentioned this was not because I thought it
> was a problem but because I thought it helped rule out a problem with how
> the jsp's were compiled. I'm not certain if my logic is sound, but I
> thought since it was not working, later did work, and the time stamp had
> not been updated there was likely something other than the compilation of
> the jsp's at fault.

Very occasionally between minor versions we make changes to the code
that converts JSPs to Java and correct operation *requires* that the
JSPs are recompiled. We don't do it very often but it does happen. We
try and do things in such a way that Tomcat handles this automatically
e.g. look in the changelog for bug 33453. That said, I *always* clean
out the work directory when doing any Tomcat upgrade.

Mark

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

Re: Tomcat crashes after startup

[Mark Thomas]

On 12/12/2011 20:20, Justin Larose wrote:
> Group,
> 
> Can anyone help me with this error below from the catalina.log?
> I have attached my server.xml as well. I have done some searches on the 
> internet and cannot find much on this error.
> 
> SEVERE: Error initializing endpoint
> java.io.IOException: AnyCert TrustManagerFactory not available

Seems pretty clear to me.

> 

Fix your broken connector configuration or provide a JSSE implementation
that includes this custom truststoreAlgorithm.

Mark

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

Re: Tomcat 6: what are the risks of not using Security Manager

[Mark Thomas]

jwklomp  wrote:

>
>Hello,
>
>I'm migrating existing applications to Tomcat and setting Tomcat up as
>described in the 'Security Configuration Benchmark for Apache Tomcat
>5.5/6.0' of the Center of Internet Security. 
>
>The benchmark recommends enabling the Security Manager. However, I'm
>experiencing that none of the apps run 'out of the box' with the
>Security
>Manager enabled. I'm contemplating not activating it, but find it hard
>estimate the risk.
>
>Our Security department is worried that without the Security Manager
>enabled, hackers can gain access to restricted packages, take control
>over
>Tomcat and 'hop' to other applications and machines (so basically this
>would
>imply activating the Security Manager for all applications). 
>
>My question is: how secure is Tomcat without the Security Manager
>enabled
>(assuming other points from the CIS benchmark have been implemented).
>Is the
>Security Manager the guard against 'hopping' to other applications, or
>does
>Tomcat without the Security Manager already prevent this?
> 
>Regards, Jan-Willem
>-- 
>View this message in context:
>http://old.nabble.com/Tomcat-6%3A-what-are-the-risks-of-not-using-Security-Manager-tp32973301p32973301.html
>Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

It may have improved but the last time I looked at the CIS
recommendations my immediate impression was that it was written by folks
with zero to little understanding of Tomcat.

Without the security manager, if an application has a serious security
vulnerability then an attacker can potentially do anything the user
running the Tomcat process can do. This is why you should never run
Tomcat as root.

With the security manager, the web application runs in a sandbox that
further limits what it can do.

The problem with the security manager is that if an app is not written
to run under a security manager - so it uses doPrivileged() - then you
often end up having grant so many permissions that there is no point
using the security manager. The other risk is that you miss a necessary
permission and break the app. My own view is that unless the app has
been written to use a security manager from the beginning the
availability risk using one creates is greater than any confidentiality
risk that using one mitigates. However, each situation is different. YMMV.

Mark

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

Re: dbcp is mixing up connections

[Mark Thomas]

On 15/12/2011 12:12, Aitor Garcia | Tempel.es wrote:
> I don't know if this is a tomcat bug.

This is clearly not a Tomcat bug. This comes under the category of "user
error".

Mark

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

Re: Tomcat 6.0.35 NIO CometProcessor redeploy issue

[Mark Thomas]

On 18/12/2011 16:13, Peter Balogh wrote:
> Hi,
> 
> I'm not sure, if it's the right list to ask for help in this.
> I'm using Tomcat 6.0.35 from Eclipse.
> If I change the webapp, and publish it, the next request for the
> CometProcessor implementation never ends (I'm inspecting the behavior in
> firebug).
> Restarting the server seems to fix the problem.
> Has anyone met this issue?

Not that I am aware if but depending on what Eclipse is doing behind the
scenes this might or might or might not be a Tomcat bug.

> Is there any way to prevent it?

If you can reproduce this without any Eclipse involvement then please
raise a Bugzilla entry and I'll take a look at what is going on.

Mark

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

Re: Tomcat 6.0.35 NIO CometProcessor redeploy issue

[Mark Thomas]

On 19/12/2011 17:50, Peter Balogh wrote:
> Hi Mark,
> 
> I've tried to reproduce the issue without Eclipse, but I couldn't.
> The only way I could make tomcat to reload my app was to change the
> autoDeploy tag to true in the server.xml, so I'm not sure, if it's not
> tomcat related.
> Can changing this small change in the server xml make a difference?

Well, Tomcat isn't going to deploy the updated WAR unless that is set to
true. See the docs for details.

> Should I try reporting this to the eclipse forums?

That looks like the right place to start to me.

Mark

> 
> Thank you for your help,
> Best regards,
> Peter Balogh
> 
> On 2011.12.19. 17:00, Mark Thomas wrote:
>> On 18/12/2011 16:13, Peter Balogh wrote:
>>> Hi,
>>>
>>> I'm not sure, if it's the right list to ask for help in this.
>>> I'm using Tomcat 6.0.35 from Eclipse.
>>> If I change the webapp, and publish it, the next request for the
>>> CometProcessor implementation never ends (I'm inspecting the behavior in
>>> firebug).
>>> Restarting the server seems to fix the problem.
>>> Has anyone met this issue?
>> Not that I am aware if but depending on what Eclipse is doing behind the
>> scenes this might or might or might not be a Tomcat bug.
>>
>>> Is there any way to prevent it?
>> If you can reproduce this without any Eclipse involvement then please
>> raise a Bugzilla entry and I'll take a look at what is going on.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: High memory consumption caused by BLOCKED Threads

[Mark Thomas]

On 22/12/2011 09:05, Violeta Georgieva wrote:
> Hi,
> 
> I am using Tomcat 6.0.29 and SUN JVM.
> I experience high memory consumption caused by BLOCKED Threads.

Blocked threads will not cause high memory consumption.

> I would appreciate any help or suggestion how to solve the problem.

Try telling us what the real problem is rather than what you think the
cause is.

Mark

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

Re: Error in documentation

[Mark Thomas]

On 22/12/2011 15:00, Peter Šály wrote:
> Hi all,
> 
> I want to point on wrong setting example for tomcat manager in the
> documentation:
> http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access
> .
> 
> 

That example is correct.

> What should I put in tomcat-users.xml to access tomcat manager web app??

If you mean the HTML interface rather than the script interface, you
need the manager-gui role.

Mark

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

Re: Tomcat CsrfPreventionFilter - LRU Cache

[Mark Thomas]

On 23/12/2011 19:45, Ganesh Dhakshinamurthy wrote:
>>
>> Hi
>> I recently came across an issue reported regarding the LRU
>> cache implementation in CsrfPreventionFilter. It was reported that FIFO was
>> implemented instead of LRU. We are facing an issue in our application due
>> this, [Nonce tokens getting rejected]. I searched in the bugs database to
>> check if this was reported, but couldn't find any. Can somebody please let
>> me know if this is a known issue and something is on the works to fix it?

The last time it came up, no conclusion was reached as to which is the
best approach: LRU or FIFO. There are arguments for both which probably
means it really needs to be configurable.

Mark

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

Re: Odd NIO connector behavior

[Mark Thomas]

On 23/12/2011 23:39, Matthew Tyson wrote:
> Hello,
> 
> We have been having quite a few problems with using long-polling
> connections in Tomcat, via the NIO connector.  Upgrading to Tomcat 7.0.23
> definitely improved things, but we are still seeing major issues.

Glad to hear things are getting better. No so glad to hear you are still
having problems.

> The problems only crop up after a couple minutes under some load (modest
> load, around 2-3 connections per second).

That's pretty low load.

> One very clear problem I am looking at right now is that the service method
> on a servlet is continually being called, although there is no traffic
> coming into tomcat from that remote IP (we verified this at the ethernet
> device).

Hmm. Very strange that the service method is being called. There needs
to be a complete and valid set of HTTP headers for that to happen and
the request/response gets recycled afterwards so the data shouldn't get
processed twice.

> The logging statement at the beginning of the service method is being
> executed every so often, like so:

> logger.info("REQUEST: " + request.getRemoteAddr() + "  " +
> request.getMethod() + "  " + request.getQueryString());
> 
> INFO  2011-12-23 15:30:50,860 org.cometd.server.CometdServlet REQUEST:
> 75.149.42.46  POST  null
> INFO  2011-12-23 15:31:02,484 org.cometd.server.CometdServlet REQUEST:
> 75.149.42.46  GET
>  
> message=%5B%7B%22channel%22%3A%22%2Fmeta%2Fconnect%22%2C%22connectionType%22%3A%22callback-polling%22%2C%22advice%22%3A%7B%22timeout%22%3A0%7D%2C%22id%22%3A%22354%22%2C%22clientId%22%3A%222b611tiekwk6p2mfh5bye3bm6y7l%22%7D%5D&jsonp=dojo.io.script.jsonp_dojoIoScript135._jsonpCallback
> INFO  2011-12-23 15:31:28,512 org.cometd.server.CometdServlet REQUEST:
> 75.149.42.46  POST  null
> INFO  2011-12-23 15:31:36,571 org.cometd.server.CometdServlet REQUEST:
> 75.149.42.46  POST  null

Odd. So there are at least two different requests being processed here.

> But again, there is no traffic from that IP.  I'm not sure if this is some
> sort of loop, a very long delay, or other connections being mixed up.

I'm not aware of any connection mix up issues that might explain this.

>  Probably the last, since I don't see any loop pattern, and it has
> continued without any traffic for almost a half an hour now.
> 
> Thoughts?

We need more information :)

If you can create a simple web application that reproduces this I'd be
happy to take a look. I suspect that is non-trivial so I'll suggest a
couple of other options.

1. The simple thing is to add a stack trace to that log message so we
can see exactly what code path is triggered this.

2. How comfortable are you patching Tomcat and building it from source?
I have some debug logging sat in a git branch that I use for debugging
similar issues that will generate a lot of logging but show exactly what
is happening. I can either provide you with the patch or an updated JAR
(or JARs) that you can drop into a 7.0.23 instance.

Mark

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

Re: Tomcat HTTPS Connector Stops working after an hour

[Mark Thomas]

On 27/12/2011 08:55, Saravanan L wrote:
> Tried netstat. 443 is listening, but I cannot connect to it.

I assume it shows no open connections either.

> Secondly Thread dump - I could not find any signs of problem or anything
> relative to the current issue in the threaddump [Please find the
> threaddump in my previous post].

Yep, that looks like 200 idle threads to me.


Looking back through this thread I see a number of most likely unrelated
issues being treated as the same problem.

Reviewing the thread:

1. acceptCount=1 is a crazily high number. That you see odd effects
with this does not surprise me. acceptCount is only for handling
infrequent, short, very high spikes in load.

2. maxThreads=5000 is very high. Given that you handled ~10k requests in
2 hours it appears that maxThreads should be reduced by several orders
of magnitude.

3. A 504 response code is a gateway timeout. Tomcat does not issue this
on its own. Either you have a proxy in front of Tomcat or your
application is returning this value.

4. There are settings in your server.xml that were dropped a couple of
versions ago.


I suggest the following:
- restore the threadpool and acceptcount defaults
- remove the old settings


Run your tests and then diagnose the fault that appears. If you need
pointers, ask here.


Mark

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

Re: Tomcat HTTPS Connector Stops working after an hour

[Mark Thomas]

On 27/12/2011 10:47, Saravanan L wrote:
> 3. A 504 response code is a gateway timeout. Tomcat does not issue this
> on its own. Either you have a proxy in front of Tomcat or your
> application is returning this value.
> 
> A. Yes the proxy relayed this message,  it seems the tomcat did not
> respond with any message at all.

Which is the first mention in this thread that you are accessing Tomcat
via a proxy which makes most of the previous contents of this thread
null and void.

I think you need to start again with a more complete description of how
your system is configured. This is look less and less like a Tomcat
issue and more and more like a poorly configured proxy.

Mark

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

Re: Odd NIO connector behavior

[Mark Thomas]

On 25/12/2011 02:17, Matthew Tyson wrote:

>> INFO  2011-12-24 10:25:35,578 COMET  REQUEST: 75.149.42.46  POST  null |
>> TRACE:
>> java.lang.Throwable
>> at org.cometd.server.CometdServlet.service(CometdServlet.java:149)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>> at
>> com.company.util.filter.MonitoringFilter.doFilter(MonitoringFilter.java:47)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>> at
>> com.company.util.tomcat.SecureProxyValve.invoke(SecureProxyValve.java:57)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
>> at
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1571)
>>  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:662)

That all looks pretty normal. What I am wondering now, is what is
calling NioEndpoint.processSocket()

I'd suggest if at all possible, setting up your Tomcat instance to allow
remote debugging and then once the instance gets into this state check
what is calling that code. It gets called far too often to output a
stack trace every call during normal operation.

>>> 2. How comfortable are you patching Tomcat and building it from source?
>>> I have some debug logging sat in a git branch that I use for debugging
>>> similar issues that will generate a lot of logging but show exactly what
>>> is happening. I can either provide you with the patch or an updated JAR
>>> (or JARs) that you can drop into a 7.0.23 instance.
>>>
>> Does the stack trace shed any light?  If not, I can try the JAR or the git
>> branch.

I'm not sure my debug code is in the right place for this. If the
debugging above isn't possible then patching Tomcat may be the only
option. It sounds like you know enough of what you are doing to just
patch it if required (noting that any such patch will generate a lot of
output in normal running) but feel free to ask here if I have misjudged
things.


> I noticed in the stack trace our custom valve.  Its a very simple valve
> that just checks what port a request came in on and sets a flag on the
> request object:
> 
>  public void invoke(Request req, Response resp) throws IOException,
> ServletException {
> 
> if (req.getLocalPort() == secureProxyPort) {
> req.setSecure(true);
> req.setServerPort(serverPort);
> }
> 
> if (getNext() != null) {
> getNext().invoke(req, resp);
> }
> }
> 
> I disabled the valve, and so far, the repeating requests have stopped.  (I
> should mention that asyncSupported is true on this valve).
> 
> Any thoughts on why this would cause this problem?

Strange. I don't see anything wrong with that but if there is a
threading problem at the bottom of this, the timing change this creates
may be enough to trigger whatever the problem is.

Mark

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

Re: [OT] ClassFormatException: Invalid constant pool reference

[Mark Thomas]

On 28/12/2011 10:24, Denis Ivanov wrote:
> Can you post the full stack trace?
>> Dec 27, 2011 8:50:26 AM org.apache.catalina.startup.HostConfig
>> checkResources INFO: Undeploying context [/GlobziWebApplication] 
>> Dec 27, 2011 8:50:26 AM org.apache.catalina.startup.HostConfig
>> deployWAR INFO: Deploying web application archive
>> GlobziWebApplication.war Dec 27, 2011 8:50:26 AM
>> org.apache.catalina.startup.HostConfig deployWAR SEVERE: Error
>> deploying web application archive GlobziWebApplication.war 
>> org.apache.tomcat.util.bcel.classfile.ClassFormatException:
>> Invalid constant pool reference: 12034. Constant pool size is:
>> 1486 at
>> org.apache.tomcat.util.bcel.classfile.ConstantPool.getConstant(ConstantPool.java:184)
>>
>> 
at
org.apache.tomcat.util.bcel.classfile.ConstantPool.getConstant(ConstantPool.java:203)
>> at
>> org.apache.tomcat.util.bcel.classfile.Attribute.readAttribute(Attribute.java:109)
>>
>> 
at org.apache.tomcat.util.bcel.classfile.Code.(Code.java:86)
>> at
>> org.apache.tomcat.util.bcel.classfile.Attribute.readAttribute(Attribute.java:140)
>>
>> 
at
org.apache.tomcat.util.bcel.classfile.FieldOrMethod.(FieldOrMethod.java:58)
>> at
>> org.apache.tomcat.util.bcel.classfile.Method.(Method.java:72)
>>
>> 
at
org.apache.tomcat.util.bcel.classfile.ClassParser.readMethods(ClassParser.java:268)
>> at
>> org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:128)
>>
>> 
at
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:1967)
>> at
>> org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:1914)
>>
>> 
at
org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:1905)
>> at
>> org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:1905)
>>
>> 
at
org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:1905)
>> at
>> org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1828)
>>
>> 
at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1295)
>> at
>> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:896)
>>
>> 
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:322)
>> at
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>>
>> 
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89)
>> at
>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5103)
>>
>> 
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
>> at
>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:812)
>>
>> 
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:787)
>> at
>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:607)
>>
>> 
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:932)
>> at
>> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:723)
>>
>> 
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
>> at
>> org.apache.catalina.startup.HostConfig.check(HostConfig.java:1363)
>>
>> 
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:294)
>> at
>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>>
>> 
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89)
>> at
>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1233)
>>
>> 
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1391)
>> at
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1401)
>>
>> 
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1380)
>> at java.lang.Thread.run(Thread.java:636)

https://issues.apache.org/bugzilla/show_bug.cgi?id=52326 ?

Mark

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

[SECURITY] Apache Tomcat and the hashtable collision DoS vulnerability

[Mark Thomas]

You may have read about a recently announced vulnerability rooted in the
Java hashtable implementation [1]. Since Apache Tomcat uses a hashtable
for storing HTTP request parameters, it is affected by this issue.

As per [1], it appears that Oracle will not be providing a fix for this
vulnerability with in the JRE.

Tomcat has implemented a work-around for this issue by providing a new
option (maxParameterCount) to limit the number of parameters processed
for a single request. This default limit is 1: high enough to be
unlikely to affect any application; low enough to mitigate the effects
of the DoS.

The work-around is available in:
trunk
7.0.23 onwards
6.0.35 onwards

The work-around will also be available in 5.5.35 once released.

If using an earlier version of Apache Tomcat that does not have the
maxParameterCount attribute available, limiting the maxPostSize to a few
10's of kB should also mitigate the issue although it may cause issues
for some applications.

While this is not viewed as a vulnerability in Apache Tomcat, the Apache
Tomcat security team is making this announcement due to the high
likelihood that applications will be affected by this issue and to make
users aware of the available work-arounds.

The Apache Tomcat security team

[1] http://www.nruns.com/_downloads/advisory28122011.pdf

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

Re: how can I figure out if tomcat is blocking and needs more threads? production tomcat monitoring tips.

[Mark Thomas]

On 28/12/2011 22:27, S Ahmed wrote:
> While benchmarking, I want to know if/when tomcat requires more threads
> (maxThreads).
> 
> How can I figure this out?

Look in the logs. Tomcat reports the first time (and only the first
time) it hits maxThreads.

Mark

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

Re: Tomcat HTTPS Connector Stops working after an hour

[Mark Thomas]

On 29/12/2011 08:51, Saravanan L wrote:
> *Point 1 and 2. *
> 1. When I remove acceptCount=1 My tomcat 7 works fine.

So remove it and don't put it back.

> 2. But I had  the same property in tomcat 6 and it worked fine on that.

Clearly something is broken with your app / Tomcat 7 configuration.

Using maxThreads=5000 when you are only servicing 9000 requests in 1800
seconds with an average processing time of less than 1s per request is
not only excessive it will mask any connection related problems you do
have. The default of 200 should be fine.

Since you are using APR, you don't need a thread to maintain a
keep-alive connection so I would reduce maxThreads to no more than 20
for now to aid debugging. Once you have fixed the problem, then you can
restore the default.

> A. I tried remove and altering some variables to check this problem.
> Mistakenly I thought acceptCount was the culprit, because
> after removing acceptCount, tomcat was running for 2 hours then 443
> connector stopped. Tomcat 6 with the same configuration (server.xml)
> works fine.

That is pretty much completely unhelpful. a) you need to tell us what
you are changing and what the results were and b) you should only change
one thing at a time.

> *Point 4*
> 4. Also found out that when it reaches 9000 connections with my existing
> connector [See below] the tomcat https [Http works fine] stops
> responding and the browser says 'Connection reset by peer'.

Connections != requests. Please make sure you use the correct
terminology because if you don't it will cause confusion.

Point was was related to old, invalid attributes you had in server.xml
that should be removed.

> A. When the request count reaches 9000, the tomcat fails within minutes.
> This depends , the last two times I tested, I was able to reproduce this.
> Log from Tomcat Server status.
> (after 1/half hour)
> Max threads: 5000 Current thread count: 209 Current thread busy: 2
> Keeped alive sockets count: 56
> Max processing time: 300477 ms Processing time: 8788.765 s Request
> count: 9926 Error count: 783 Bytes received: 0.22 MB Bytes sent: 5.43 MB

So, actions for you are:
- remove accepCount from the connector configuration
- reduce maxThreads to 20
- remove use of attributes that are not supported in Tomcat 7 (check
that each attribute is in the docs)
- explain exactly how you are testing these SSL connections (JMeter,
browser, something else?)
- repeat your test with the above settings and then report the results.
Include relevant extracts from:
- logs
- netstat output
- thread dump

Mark

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

Re: When is TC 5.5.35 scheduled to be released?

[Mark Thomas]

On 30/12/2011 09:36, Gadi Katsovich wrote:
> Hello All,
> Can anyone tell me when is TC 5.5.35 scheduled to be released?

Soon. The original plan was for it to be tagged late last week. I guess
it will be released early in the New Year.

Mark

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

Re: Odd NIO connector behavior

[Mark Thomas]

On 31/12/2011 16:35, Matthew Tyson wrote:
> On Wed, Dec 28, 2011 at 1:04 AM,  wrote:
> 
>> Matthew Tyson  wrote:
>>
>>> That's right, there is an f5 load balancer.  The valve is used to keep
>>> track of whether the request was via HTTPS or not.
>>
>> What happens if you go direct to Tomcat and bypass the F5?
>>
>>> tcpdump seems to confirm the same.  What are you thinking?
>>
>> Probably, like me, that the F5 isn't handling the Comet requests correctly.
>>
>> Mark
>>
>>
> I am trying to understand how the load balancer could cause Tomcat to
> respond with an empty 200 response to a request, without ever executing the
> service method on the servlet mapped to the url.

I've seen all sorts of odd behaviors when something is expecting HTTP
but doesn't get it.

> The inbound request to tomcat is correct, and it is sometimes
> handled correctly.   However, much of the time it is sending the empty 200.

Given that there appears to be multiple issues here, I'd suggest
concentrating on the one that is likely easiest to debug. Fix that and
then see what the other problems then look like. We might be seeing two
sides of the same issue.

My recommendation is:
- if possible, test without the F5 just to be sure this is purely a
Tomcat issue
- investigate the repeated calls to service() with no incoming request
as that is likely to be easier to debug. As per my previous suggestion,
get Tomcat into this state and then use remote debugging to see what is
calling NioEndpoint.processSocket()

Mark

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

Re: File leak in 7.0.23?

[Mark Thomas]

On 31/12/2011 13:38, Janne Jalkanen wrote:
>> Which Connector are you using?
> 
> connectionTimeout="2" 
>redirectPort="8443" 
>URIEncoding="UTF-8"
>compression="on"
>
> compressableMimeType="text/html,text/plain,text/css,text/javascript,application/json,application/javascript"
>noCompressionUserAgents=".*MSIE 6.*"/>

Is that APR/native or BIO?

Mark

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

7.0.22+ fd leak with APR/native

[Mark Thomas]

I am trying to bring together all the information I have gleaned on this
so far from the multiple threads to try and find the common factors.

So far I have:
- 7.0.21 is OK
- 7.0.22 has an fd leak
- 7.0.23 has an fd leak and may leak faster than 7.0.22
- occurs with APR/native
- does not occur with BIO
- has been observed in HTTP & HTTPS
- use of Comet does not trigger it
- use of compression does not trigger it
- separate connection and keep-alive timeouts does not trigger it

It may be related to POST processing.

I have tried (and so far failed) to reproduce this. I'll be looking at
POST processing next. In the meantime, here are some further questions
to try and narrow things down:

1. Does the application where this is observed make use of Servlet 3.0
async requests?

2. Does this leak occur when the NIO connector is used?

3. Are there any exceptions in the logs that weren't present in 7.0.21
or earlier?

4. Does the leak occur if sendfile is disabled?

I also have reviewing the 7.0.21 to 7.0.22 changes on my todo list but
there are quite a few as I was refactoring the connectors to reduce code
duplication and ironically, reduce maintenance requirements, at the time.

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

Re: 7.0.22+ fd leak with APR/native

[Mark Thomas]

On 03/01/2012 21:26, André Warnier wrote:
> Mark Thomas wrote:
>> I am trying to bring together all the information I have gleaned on this
>> so far from the multiple threads to try and find the common factors.



> Suggestion: the "large POST requests" mentioned by a couple of posters
> suggest file uploads, which may imply temporary files used to buffer the
> files being uploaded, no ?

Probably not. That code is connector agnostic. There might be something
in the APR InputBuffer though.

Mark

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

Re: 7.0.22+ fd leak with APR/native

[Mark Thomas]

On 03/01/2012 21:32, Mark Thomas wrote:
> On 03/01/2012 21:26, André Warnier wrote:
>> Mark Thomas wrote:
>>> I am trying to bring together all the information I have gleaned on this
>>> so far from the multiple threads to try and find the common factors.
> 
> 
> 
>> Suggestion: the "large POST requests" mentioned by a couple of posters
>> suggest file uploads, which may imply temporary files used to buffer the
>> files being uploaded, no ?
> 
> Probably not. That code is connector agnostic. There might be something
> in the APR InputBuffer though.

The APR InputBuffer is untouched between 7.0.21 and 7.0.22. However, I
did find an error in r1166072 that might explain the fd leak. I am
trying to reproduce it at the moment. In the meantime, if someone could
try the following patch that would be great:

Index: java/org/apache/tomcat/util/net/AprEndpoint.java
===
--- java/org/apache/tomcat/util/net/AprEndpoint.java(revision 1226551)
+++ java/org/apache/tomcat/util/net/AprEndpoint.java(working copy)
@@ -1364,7 +1364,6 @@
 } else {
 destroySocket(desc[n*2+1]);
 }
-return true;
 }
 }
 } else if (rv < 0) {


Cheers,

Mark

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

Re: 7.0.22+ fd leak with APR/native

[Mark Thomas]

On 04/01/2012 13:59, Konstantin Kolinko wrote:
> 2012/1/4 Konstantin Kolinko :
>>
>> 2. The
>> processSocket(desc[n*2+1], SocketStatus.DISCONNECT);
>> call just above the fixed line.
>>
>> It looks like a NOOP, because processSocket(long,SocketStatus) has an
>> if() that does not mention SocketStatus.DISCONNECT.
>>
>> I think it is one more way to leak sockets. This method is used only
>> in comet requests.
> 
> and I think that if() might be a cause of missing some ERROR events in comet.

Agreed.

>> Can the "if()" condition in processSocket(long,SocketStatus) be removed?
>> Besides SocketStatus.DISCONNECT. there is one more status that is not
>> mentioned in that if() and can lead to similar leaks:
>> SocketStatus.ERROR.
>>
>> The if() was added in
>> http://svn.apache.org/viewvc?view=revision&revision=944518
>>
>> I do not see a reason for this if(). The r944518 says about "running
>> with a SecurityManager" so it should have just added a
>> PrivilegedAction there.
>>
> 
> One more oddity with r944518 in AprEndpoint:
> 1. I do not understand why one has to set TCCL before calling
> getExecutor().execute(). We do not do this in other places. E.g. we do
> not do it in AprEndpoint#processSocket(long).

I suspect because the Servlet 3 Async code was re-using bits of the
Comet code (inconsistently in different ways on different connectors).

> 2. r944518 says about TCK failures, but TCK does not test comet and so
> it could not be a reason for the change in this method which is used
> only by comet.

It is only used by Comet now but r944518 pre-dates r1001698 where there
was a major refactoring of the connectors.

> So it looks that not only the if(), but the whole r944518 change in
> AprEndpoint has to be reverted.

That looks OK to me. I'll do that but run the TCKs as a double check.

Mark

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

Re: 7.0.22+ fd leak with APR/native

[Mark Thomas]

On 06/01/2012 20:13, Konstantin Kolinko wrote:
> 2012/1/6 Mark Thomas :
>>> So it looks that not only the if(), but the whole r944518 change in
>>> AprEndpoint has to be reverted.
>>
>> That looks OK to me. I'll do that but run the TCKs as a double check.
>>
> 
> I am running TestCometProcessor tests with this very change just now. ;)
> 
> (My plan is to reenable TestCometProcessor - that is revert
> http://svn.apache.org/viewvc?rev=1225632&view=rev
> but with the following change in testCometConnectorStop():
> 
> - Do not ask reader thread whether END event message was received
> over the wire, but ask the servlet directly whether the last CometEvent
> that it processed was EventType.END.  I think it would be more reliable.
> )

I'm not keen on that idea since the point of the test was to ensure that
the END event was received by the client, not that it was processed by
the Server.

> The NIO connector is OK, but I observe an issue with APR one:
> 
> In testCometConnectorStop() the test fails:
> 
> [[[
> junit.framework.AssertionFailedError: No exception in writing thread
>   at 
> org.apache.catalina.comet.TestCometProcessor.testCometConnectorStop(TestCometProcessor.java:289)
> ]]]
> 
> So no SocketException happens in the WriterThread.  At the same time
> when I ask SimpleCometServlet for the last event that it received it
> is EventType.END.
> 
> My thought is that the WriterThread does not see that the socket that
> it writes to has been closed.
> 
> (It probably is not of much concern because it happens at shutdown,
> but it might be that we are still missing something).

I'd be happy for the lack of a WriterThread exception to trigger a log
message rather than a test failure.

Mark

> I thought that maybe during shutdown the
> #processSocket(long,SocketStatus) that uses an executor to run the
> event did not have chance to run,  but because the END event was
> received by servlet I think that it did run.
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> 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: SSL Configuration Errors

[Mark Thomas]

On 06/01/2012 22:12, Christopher Schultz wrote:
> Pid,
> 
> On 1/6/12 4:30 AM, Pid wrote:
>> On 05/01/2012 18:22, Justin Larose wrote:
>>> truststoreFile="F:\Serena\Dimensions 2009 R2\Common
>>> Tools\Tomcat 7.0\conf\wcmdev-ssl.jks"
> 
>> truststoreType has the default, you can remove it.

truststoreType != truststoreFile

> No, truststoreFile defaults to nothing, so he'll need to leave this
> in there.

Pid is right, truststoreType can be removed.


Mark

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

Re: file descriptor (unix socket) leak with NIO handler

[Mark Thomas]

On 07/01/2012 07:23, Arijit Ganguly wrote:
> At my anticipated connection rates (100/second), we observe the application
> to leak about 150 file handles (corresponding to Unix sockets) each day.

That is a pretty small percentage of connections that results in a leak.
That suggests this could be tricky to reproduce and track down.

> I did some investigation on the issue by connecting to the application via
> JMX. It seems like this increase in Unix socket file handles is due to
> improperly closed connections

Almost certainly.

> since I am also able to reproduce the same
> unix socket leak by invoking stop() on the HTTP Connector via JMX. Just
> before stopping the connector my application had 4000 open connections
> (lsof showed these as 4000 IPv6 file handles). On invoking stop() via JMX,
> I the number of IPv6 file went down to about 70, while the number of unix
> socket file handles went up by 4000. It seems that these incorrectly closed
> connections then incarnate as Unix socket handles.

The stop() issue should be easier to reproduce and easier to fix. Please
create a bugzilla issue for this particular problem.

> I have tried different versions of tomcat 6.0.32, 6.0.35, 7.0.21 and
> tomcat7.0.23 – they all have this issue. My application is using the
> default configuration of the NIO Connector. I dont think Comet or SendFile
> are being used. Furthermore, no unix sockets show up when I use Blocking IO
> (default HTTP handler).

Thanks, that helps.

> I would appreciate the help of the community in addressing this issue.

We can take a look at the NIO code but finding leaks like this purely
from code inspection is tricky to say the least.

Anything you can do to increase the rate of the leak and/or to provide a
test case that demonstrates the issue would be useful.

Mark

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

Re: SEVERE: Allocate exception for servlet helloworld Apache-Tomcat 7.0.23

[Mark Thomas]

On 10/01/2012 18:28, Alastair Baldwin wrote:
> Dear users
> 
> I'm unable to get a Hello World Servlet running from my browser. 
> 
> Configuration:
> Windows XP Version 2002 service pack 3
> Apache-tomcat-7.0.23-windows-x86
> CATALINA_HOME = c:\apache-tomcat-7.0.23-windows-x86\apache-tomcat-7.0.23
> CLASSPATH= 
> .;c:\apache-tomcat-7.0.23-windows-x86\apache-tomcat-7.0.23\servlet-api.jar 
>  JAVA_HOME=c:\Program Files\jdk1.7.0
> 
> 
> compiling as javac HelloWorldServlet.java -cp 
> CATALINA_HOME/lib/servlet-api.jar 
> 
> I manually copy  HelloWorldServlet.class  to the apress directory under 
> webapps

That should be apress/WEB-INF/classes//HelloWorldServlet.class

Mark

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

Re: SEVERE: Allocate exception for servlet helloworld Apache-Tomcat 7.0.23

[Mark Thomas]

On 10/01/2012 18:38, Alastair Baldwin wrote:
> Excuse my ignorance, but I had the package information in place and had the 
> same error
> so I tried to simplify it by removing the package details from 
> HelloWorldServlet.java
> and the webapps directory. Is a package essential for tomcat to work?

Using packages is strongly recommended.

Placing classes under WEB-INF/classes is required.

Mark

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

Re: SEVERE: Allocate exception for servlet helloworld Apache-Tomcat 7.0.23

[Mark Thomas]

On 10/01/2012 19:14, Alastair Baldwin wrote:
> My HelloWorldServlet.class is in CATALINA_HOME/webapps/WEB-INF/Classes

Which should be:
CATALINA_HOME/webapps/WEB-INF/classes

Case matters.

Mark

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

Re: SEVERE: Allocate exception for servlet helloworld Apache-Tomcat 7.0.23

[Mark Thomas]

On 10/01/2012 19:20, Mark Thomas wrote:
> On 10/01/2012 19:14, Alastair Baldwin wrote:
>> My HelloWorldServlet.class is in CATALINA_HOME/webapps/WEB-INF/Classes
> 
> Which should be:
> CATALINA_HOME/webapps/WEB-INF/classes

Scratch that. It should be:
CATALINA_HOME/webapps//WEB-INF/classes

Mark

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

Re: Really block a directory

[Mark Thomas]

On 11/01/2012 13:00, Luciano Andress Martini wrote:
> I need to block a directory in Tomcat, with all the files and
> sub-dirs,  i cant change the path of this directory. =[
> Like we do in Apache2, and without changing files permission.
> 
> Its possible?

Yes.

Write a Servlet. Hard code it to return 404 and map it to the path that
equates to the directory.

Mark

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

Re: Excessive CPU w/APR Connectors on tomcat-native 1.1.22

[Mark Thomas]

On 11/01/2012 22:42, Marvin Addison wrote:
> We are seeing excessive CPU burn (top > 300% on multicore machine) in
> multiple versions of Tomcat that use APR connectors exclusively.  The
> problem does not correlate with load.  We initially saw it on 6.0.35
> and subsequently on 7.0.23 as we attempted to upgrade around the
> problem.  We have determined that the component common to both
> versions is tomcat-native 1.1.22.  (We were not seeing this behavior
> on our previous component mix of 6.0.26/1.1.20.)

Can you confirm whether or not the issue exists with 6.0.26 and 1.1.22?
It would be helpful to try and track down which component is the root of
the issue.

How long do the periods of high CPU usage last?

> Graphs of CPU usage over time show a sharp increase when a second
> thread enters sendbb; conversely there is a sharp decrease as soon as
> all but a single thread drop out of the method.  Additionally, there
> may be a correlation with CPU usage and the number of threads in
> sendbb; for example, the CPU burn may be greater when three threads
> are in sendbb versus two.

How sure are you that the CPU is being burned in the threads that are in
sendbb? Just because the CPU usage correlates with threads being in that
method it doesn't necessarily mean that is where the CPU is being used.

> This feels like a concurrency bug: hard to reproduce, sporadic, and
> correlates with number of threads acting on the same code path.
> Please let me know if you'd like me to do anything further that may
> help determine whether this is, in fact, a bug.  I'm happy to create a
> bug report if needed.

Answers to the above questions would help with the analysis of this
issue. Assuming that this is a concurrency issue, then code inspection
is likely to be the best chance of finding the issue. If we can get to a
point where we can say upgrading this one component from x.y.z to
x.y.z+1 triggers the issue that will narrow down where we have to look.

Mark

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

Re: Problem with using context version

[Mark Thomas]

On 12/01/2012 17:06, Alexander Azarov wrote:
> Hello,
> 
> I have a tough problem. I have a web application written in Scala and
> I'm deploying it to Tomcat 7. This application uses Twitter Eval
> library to read its configuration (basically Twitter Eval compiles a
> Scala file on the fly and returns an instance, so it becomes possible
> to write an app configuration in Scala).
> 
> The application runs fine under Tomcat 7, but I have a problem
> deploying it with context version
> (http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming)
> -- Twitter Eval fails to compile the configuration file and the stack
> trace goes deep into Scala compiler. I've created the minimal example
> project to show the effect: https://github.com/alaz/tweval (the stack
> trace is shown there as well).
> 
> In order to eliminate the possibility Twitter Eval or Scala
> library/compiler may be guilty, I've tried to build up a command-line
> example and run it in a directory with name containing ##... it's here
> https://github.com/alaz/tweval--2 . It works fine.
> 
> Looking forward to any help,

Almost certainly some form of URL class loader issue triggered by the
presence of the '##' sequence.

Something else to check is a multi-level context such as foo#bar.war

If foo.war works and foo#bar.war doesn't and neither does foo##1.war
then my money will be on the class loader.

Mark

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

Re: Problem with POST requests not removing JSESSIONID in tomcat 6.0.35

[Mark Thomas]

On 16/01/2012 12:45, Daniel Pyykkö wrote:
> Hi,
> 
> I seem to have found a problem in tomcat 6.0.35 that did not exist in
> 6.0.32 or prior to that version that I would like to know if I should
> file as a bug or if it exists a solution to it (it seems to be a
> coding bug but just in case, I run tomcat on a MAC).

And what exactly is the problem?

> Now to my problem/question. Is it just a bug that the method
> parseSessionId is no longer called by the method postParseRequest or
> how/where should the JSESSIONID be removed from the requestURL? Or
> could it be on purpose that the JSESSIONID no longer is removed from
> the requestURL?

The change is deliberate. JSESSIONID is a valid path parameter.

Mark

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

Re: Problem with POST requests not removing JSESSIONID in tomcat 6.0.35

[Mark Thomas]

On 16/01/2012 14:06, Daniel Pyykkö wrote:
> Hi Mark,
> 
> So this means that the JSESSIONID is no longer removed from the
> requestURL by tomcat (and is thereby now propagated all the way) and
> we as developers of our product must now take that in consideration
> that JSESSIONID is returned as part of the URI when calling for
> example httpServletRequest.getRequestURI()?

Yes.

> So what you are saying is
> that this is a new behavior in tomcat 6.0.35,

No, this change was as of 6.0.33.

> is this stated
> somewhere in the changelog?

Yes. Look for "path parameters".

Mark

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

Re: TC7 + AntCompiler problems with whitespace in pathname

[Mark Thomas]

On 16/01/2012 23:14, epr...@orpheus.fr wrote:
> ### Summary
> 
> TC fails to compile JSP when 1) the compiler is AntCompiler and 2) there
> is a whitespace somewhere in the pathname to TC home dir.



> ### Questions
> 
> Q1 - Does somebody already have seen this problem?

I don't recall seeing this particular, but it doesn't surprise me.

> Q2 - Do you think I should fill a bug?

Please. And include the steps you are using to configure Ant as the
compiler in case there is something odd there.

Mark

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

[SECURITY] CVE-2011-3375 Apache Tomcat Information disclosure

[Mark Thomas]

CVE-2011-3375 Apache Tomcat Information disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- Tomcat 7.0.0 to 7.0.21
- Tomcat 6.0.30 to 6.0.33
- Earlier versions are not affected

Description:
For performance reasons, information parsed from a request is often
cached in two places: the internal request object and the internal
processor object. These objects are not recycled at exactly the same time.
When certain errors occur that needed to be added to the access log, the
access logging process triggers the re-population of the request object
after it has been recycled. However, the request object was not recycled
before being used for the next request. That lead to information leakage
(e.g. remote IP address, HTTP headers) from the previous request to the
next request.
The issue was resolved be ensuring that the request and response objects
were recycled after being re-populated to generate the necessary access
log entries.

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Tomcat 7.0.x users should upgrade to 7.0.22 or later
- Tomcat 6.0.x users should upgrade to 6.0.35 or later

Credit:
The issue was initially reported via Apache Tomcat's public issue
tracker with the potential security implications identified by the
Apache Tomcat security team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=51872


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

[SECURITY] CVE-2012-0022 Apache Tomcat Denial of Service

[Mark Thomas]

CVE-2012-0022 Apache Tomcat Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- Tomcat 7.0.0 to 7.0.22
- Tomcat 6.0.0 to 6.0.33
- Tomcat 5.5.0 to 5.5.34
- Earlier, unsupported versions may also be affected

Description:
Analysis of the recent hash collision vulnerability identified unrelated
inefficiencies with Apache Tomcat's handling of large numbers of
parameters and parameter values. These inefficiencies could allow an
attacker, via a specially crafted request, to cause large amounts of CPU
to be used which in turn could create a denial of service.
The issue was addressed by modifying the Tomcat parameter handling code
to efficiently process large numbers of parameters and parameter values.

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Tomcat 7.0.x users should upgrade to 7.0.23 or later
- Tomcat 6.0.x users should upgrade to 6.0.35 or later
- Tomcat 5.5.x users should upgrade to 5.5.35 or later

Credit:
The inefficiencies in handling large numbers of parameters were
identified by the Apache Tomcat security team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html

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

Re: TC7 + AntCompiler problems with whitespace in pathname

[Mark Thomas]

On 17/01/2012 12:22, epr...@orpheus.fr wrote:
> Forgot to mention:
> - The description pertains to the Linux 32 bits test case + Oracle JDK 1.6.
> - For the Windows x64 + JDK 1.7 test case, replace "javac1.6" by
> "javac1.7" and you're done.

That looks good to me. Please open a bug and I'll take a look.

Mark

> 
> Erik
> 
>>> Please. And include the steps you are using to configure Ant as the
>>> compiler in case there is something odd there.
>>
>> @mark: do you think the description below is concise enough ?
>>
>> Erik
>>
>> - Download apache-ant-1.8.2-bin.tar.gz
>> - Extract to any temp directory
>> - Copy apache-ant-1.8.2/lib/ant.jar +
>> apache-ant-1.8.2/lib/ant-launcher.jar to /lib
>> - Forget ant (extracted directory can be deleted)
>> - Copy JDK lib/tools.jar to /lib (mandatory when fork=false, see
>> below)
>> - Update original web.xml this way (starting at line 230):
>> 
>> jsp
>> org.apache.jasper.servlet.JspServlet
>> 
>> fork
>> false
>> 
>> 
>> xpoweredBy
>> false
>> 
>> 
>> compiler
>> javac1.6
>> 
>> 
>> suppressSmap
>> true
>> 
>> 3
>> 
>> - Delete /work to be sure not to run with any previous compilation
>> results
>> - Run tomcat with startup.sh
>> - Go to http://localhost:8080
>> - When TC home dir absolute pathname contains a space, it fails as
>> described by my first mail.
>>
>> That's it.
>>
>>> On 16/01/2012 23:14, epr...@orpheus.fr wrote:
 ### Summary

 TC fails to compile JSP when 1) the compiler is AntCompiler and 2)
 there
 is a whitespace somewhere in the pathname to TC home dir.
>>>
>>> 
>>>
 ### Questions

 Q1 - Does somebody already have seen this problem?
>>>
>>> I don't recall seeing this particular, but it doesn't surprise me.
>>>
 Q2 - Do you think I should fill a bug?
>>>
>>> Please. And include the steps you are using to configure Ant as the
>>> compiler in case there is something odd there.
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 
> 
> 
> -
> 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: Changes to deployed .war file not copied to unpacked war directory at Tomcat startup?

[Mark Thomas]

On 18/01/2012 20:31, Aron Roberts wrote:
>   With apologies if this turns out to be a truly newbie question, or
> has been answered in the archives (the MARC archives are
> inaccessible today due to SOPA Blackout Day) ...
> 
>   We've reproducibly observed the following with respect to
> updating the contents of unpacked/exploded WAR directories,
> and wish to ask whether this is the intended behavior:
> 
>  With Tomcat 6.0.33, running on various recent Linux releases (e.g.
> Fedora 15, Ubuntu 10), and with default settings of 'unpackWARs="true"
> autoDeploy="true"' for the default host in
> CATALINA_HOME/conf/server.xml:
> 
>  1. Stop Tomcat.
>  2. Copy an updated WAR file ('cspace-ui.war') to
> $CATALINA_HOME/webapps (the default appBase directory).
>  3. Start Tomcat.
> 
>  Following Tomcat startup:
>  * Any changes that had been made within the newly-copied 'cspace-ui.war' WAR
> file, such as additions or deletions of files in the WAR ...
>  * Are *not* also appearing within the corresponding unpacked/exploded WAR
> directory, 'cspace-ui' - if that directory already existed at Tomcat startup.
> 
>  This appears on its face to be problematic.  Following Tomcat
> startup, we would intuitively expect that changes made within an
> updated WAR file - copied when Tomcat was not running - would soon
> appear, as well, within the corresponding unpacked/exploded WAR
> directory.  And it isn't readily evident to us from this document why
> it might not be so:
> 
>  http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
> 
>  The following related behaviors do work as we would expect:
> 
>  * If Tomcat is already running, any changes made to the
> 'cspace-ui.war' WAR file, once copied to
> $CATALINA_HOME/webapps (e.g. an autoDeploy scenario),
> soon appear as well within the
> corresponding unpacked/exploded WAR directory, 'cspace-ui.
> 
>  * If the unpacked/exploded WAR directory, 'cspace-ui', corresponding
> to the newly copied WAR file, 'cspace-ui.war', doesn't already exist,
> it will be duly created on Tomcat startup.
> 
>Other details that may potentially be relevant:
>  * This WAR's purpose is to simply package up a collection of HTML,
> JavaScript, CSS, JSON and properties files, which are used by another,
> Java-based web application.
>  * Its context.xml and web.xml files are truly minimal, consisting of
> just XML declarations and root elements.  (These can be gladly
> provided, along with any other requested details, in a follow-up
> upon request.)
> 
>  Thoughts?

The behaviour is entirely as expected. Tomcat has no way of telling that
the WAR has been updated while Tomcat is not running. Figuring out that
something had changed would be non-trivial.

The way to handle this simple. If you update a WAR file while Tomcat is
shut down, you *must* delete any associated unpacked directory as well.

Mark

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

Re: Per-user management rights

[Mark Thomas]

On 20/01/2012 15:19, Tim De Pauw wrote:
> I assume I'm doing something fundamentally wrong here, but the docs
> don't seem to cover this sort of thing explicitly. I guess I could
> create separate hosts for each app and user, but that seems tedious and
> unnecessary.
> 
> Any pointers? Thanks.

You can't do what you want to do with the Manager app. It doesn't
support that granularity of security. You can control individual
operations but not the combination of operation *and* context.

Multiple hosts would give you more control but a user would still be
able to deploy any context on the host on which they had deploy permission.

Mark

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

Re: CVE-2012-0022 details

[Mark Thomas]

On 21/01/2012 12:02, David Jorm wrote:

> The point of my question was to check whether my understanding of the
> CVE-2012-0022 issue is complete, i.e. whether the issue is just slow
> processing leading to a DoS when a very large number of parameters is
> received with a request.

Correct. CVE-2012-0022 relates solely to the number of parameters being
processed.

> , or whether there is some further complexity that I have overlooked.

Not that the Tomcat security team is aware of.

Mark

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

[ANN] Apache Tomcat 7.0.25 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.25

This release includes numerous bug fixes and several new features
compared to version 7.0.23. The notable new features include:
* Align the Servlet 3.0 implementation with the changes defined in the
  first maintenance release (also known as Rev. A.). See the JCP
  documentation for a detailed list of changes.
* Add support for connectors to automatically select a free port to
  bind to. This is useful when embedding and for testing.
* Update to Commons Pool 1.5.7, Commons Daemon 1.0.8 and Eclipse JDT
  compiler 3.7.1.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note that this version has 4 zip binaries: a generic one and three
bundled with Tomcat native binaries for Windows operating systems
running on different CPU architectures.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team




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

Re: Connection.close() has already been called during login

[Mark Thomas]

On 23/01/2012 03:49, removeps-c...@yahoo.com wrote:
> Am running Tomcat 7 and see this in the logs:
> 
> SEVERE: Exception performing authentication
> com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: 
> Connection.close() has already been called. Invalid operation in this state.
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>   at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
>   at com.mysql.jdbc.Util.getInstance(Util.java:381)
>   at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984)
>   at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
>   at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926)
>   at com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018)
>   at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512)
>   at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579)
>   at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408)
>   at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355)
>   at pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71)

The above line is key. You are not using Tomcat's JDBCRealm.

>   at 
> org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>   at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
>   at 
> org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773)
>   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:662)
> 
> 
> could the reason be ROOT/META-INF/context.xml which says
> 
> 
> 
> driverName="pacific.driver.PacificMysqlDriver"
>  connectionName="auth" connectionPassword="..."
>  connectionURL="pacific@jdbc:mysql://localhost:3306"
>  userTable="user" userNameCol="username" userCredCol="password"
>  userRoleTable="user_role" roleNameCol="rolename"
>  digest="SHA1"/>
> 
> That is, should I be using a datasource realm instead?

Yes.

Mark

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

Re: Cannot Validate Signature for apache-tomcat-7.0.23-windows-i64.zip

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/01/2012 20:01, Bill Rutledge wrote:
> I signed and trusted Mark's certificate:

On what basis are you trusting that that public key really does belong
to someone called "Mark Thomas"? Personally, I do rather more checks
before I'd trust someone else's public key.

> [cid:image001.png@01CCDAA8.11318280]

That's a nice series of characters. The list strips images.

> I tried to verify it, but it came up bad:
> 
> [cid:image002.png@01CCDAA8.11318280]

Can't see that image either.

Time to switch to a command line interface that you can copy and paste
stuff to/from.

The chances of a signature on a Tomcat release being bad is pretty
slim. The reasons for this are:
- - Most of the tomcat committers have met each other, verified keys and
identities and have signed each others keys
- - They have also done the same for many other folks at the ASF and are
reasonably well embedded in the ASF web of trust
- - Every Tomcat release artefact is signed by the release manager and
the signatures checked my multiple Tomcat committers
- - There is an automated process that checks every binary uploaded to
the ASF distribution area and it complains loudly if there is a
problem with the signatures (we got a nag this afternoon because I
moved some things around and missed a few files) [1]

It looks very much like your OpenPGP configuration is bad or you have
a corrupted download. Try obtaining the file from a different mirror
or direct from the ASF master copy.

I have also signed this message. If you can't verify that signature,
it is more likely to be a local issue.

Mark


[1] http://people.apache.org/~henkp/checker/sig.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPHxPyAAoJEBDAHFovYFnn/GUQAKuSm+VCV+SworFjEHRxv1mk
VyMdGEiOotxEOzdtU7iU/6yJFzgWacWRPd34kLMkzLbVjWtnllSSqZIuqSBJEEFR
g0KpC+ybYL26zikxFM3KdhEfCj9iwk8T8MXPM1y7ZqZITP+TPsV/qsRylacRTolV
Z5YQMUfxa+sdcWLKr/w3+eiRFvXuAEKOzmR6LrMlMN3DH2Vwv4z11QZoXHg0VhIr
gPwfVawN/2bkVQL/c4rgYy3ycClDYGFhHm9ixrNfgsXESuzJnaD295jiBCg+WEL+
9xA0cjDFmyzF1kHuHyxwaDxhL/gWBnImonkkjGXvKIuNiO/ADy4PAzhS7hDKNlV/
x6F+6v6KwV800b9nWJaHqBiyEhb4hbDAkUJZhmwWEvVfuMWPritw+B8uIXpHPefV
5XqoQzSR8otc6Z4/QIrk/1jcAu81WGPg5kGhWLc8+eB3fua+oMhBJN5fBdORyaL1
SnjWE1pOWprSE4yAxAVO1r31D9eexfMUH7ybOPJXUZLWxErQrOMucsahBKBiyc4w
4lybDhUooET5JOsx9MsHJZnQVK4GYnxHduPNA7PCw/aprIn+RnW3hwZ4w6iOp2/P
cu9idUfNXT1J5zP/agRfsf4KYzQJ1bVRLrXcK7prhETea1vycNT7FWQ1T4yezYvo
pBWE03DZ3S4obG4h62Ra
=oRUZ
-END PGP SIGNATURE-

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

Re: Tomcat memory requirements

[Mark Thomas]

On 25/01/2012 11:55, Luciano Andress Martini wrote:
> Hi Celso, you signature is in portuguese because that i will talk in
> portuguese...

This list conducts its business in English. We do not normally use other
languages.

If anyone feels unable to express themselves in English then by all
means include a translation of your message in your native language *in
addition* to the English version. In the unlikely event your message is
not understood (my experience of this list is that people who think they
have poor English actually have pretty good English and they can easily
be understood) the native language versions + Google translate + the
English version is usually more than enough for you to be understood.

> Tenho 12 anos de experiência com Linux e dois livros publicados, nunca
> vi um tomcat rodar sem consumir umas cacetadas de megas de memória,
> acho que o java, é uma plataforma ruim, mas que todo mundo defende e
> quer usar, talvez seja mais facil desenvolver em Java, o que eu acho
> difícil ser verdade, talvez seja mais fácil a portabilidade, mas eu
> acho improvavel o php não ser portável e não haver outras coisas
> portáveis como o ruby.
> 
> O que eu sei é que em todas as empresas que fui para resolver algum
> problema no servidor, estava na lista o tomcat que consumia memória.
> Por exemplo na empresa que estou atualmente o tomcat consome 2 GB de
> memória, num sistema que processa 2 milhões de registros, apesar de
> parecer "Explicável" isso jamais aconteceria se estivessemos usando
> php, nunca fui numa empresa e me reclamaram que uma aplicação php
> estivesse lenta ou comendo memória, isso é uma lenda.
> 
> Mas uma lenda mesmmo é dizer que o Linux vai resolver o problema do
> Java, que é comer memória até o infinito, talvez os desenvolvedores é
> que sejam muito ruins, mas estou para achar um bom então, pois toda
> empresa que fui mesmo problema, espero que eu não seja expulso desta
> lista por dizer isso. Mas infelizmente todos aqui no fundo do coração
> devem saber que é verdade.
> 
> Agora, se ta travando seu sistema começe aumentando a memória da
> máquina virtual do java.

Rather than bashing Java, it would have been more helpful to actually
answer the original poster's question (which I will do separately).

Mark

> 
> 2012/1/25, Celso Magalhães Dantas Neto :
>> Hey everyone!
>>
>> Does anyone knows where I can find any information about Tomcat memory
>> requirements?
>>
>> Here's the problem: I got a client who's running a Tomcat process in his
>> machine and it is taking around 150MB of RAM and he is complaining about
>> it. It's a webapp and for me it's normal to a webapp to take that amount of
>> memory, but I want to argue with him with some data.
>>
>> So I'm looking for some Tomcat memory requirements info, even if it's a
>> memory requirements to run Tomcat only, with no deployed webapp. It will
>> help me to argue with him.
>>
>> Thanks!
>>
>> --
>>  *CELSO DANTAS*
>>
>> *Pesquisa & Inovação
>> + 55 71 2101.4104  |  skype: celsomdantas*
>> Antes de imprimir pense em seu compromisso com o Meio Ambiente.
>>
> 
> -
> 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: Tomcat memory requirements

[Mark Thomas]

On 25/01/2012 11:45, Celso Magalhães Dantas Neto wrote:
> Hey everyone!
> 
> Does anyone knows where I can find any information about Tomcat memory
> requirements?

Tomcat needs less than 20MB to start up. Everything after that depends
on the application and the load level.

> Here's the problem: I got a client who's running a Tomcat process in his
> machine and it is taking around 150MB of RAM and he is complaining about
> it. It's a webapp and for me it's normal to a webapp to take that amount of
> memory, but I want to argue with him with some data.

I have seen Tomcat running on JVMs with memory settings ranging from
32MB to 8GB. 150MB isn't unreasonable at first glance but it all depends
on the app.

> So I'm looking for some Tomcat memory requirements info, even if it's a
> memory requirements to run Tomcat only, with no deployed webapp. It will
> help me to argue with him.

See above. The Tomcat only figure is less than 20MB.

You'll need to use a profiler to determine where the memory is actually
used.

Also note that there is a low memory usage/ low GC pause / high
throughput trade-off. Very simply you can pick any two at the expense of
the third.

Mark

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

Re: Apache Tomcat 7 JMX Monitoring

[Mark Thomas]

On 25/01/2012 14:51, Smith, Mitchell wrote:
> Hi,
> 
> I am configuring an application server:  Tomcat 7, Java 1.7
> 
> I previously used Apache Tomcat 5.5, and JDK1.5.
> 
> I had JMX monitoring enabled as below.
> 
> -Dcom.sun.management.jmxremote
> 
> -Dcom.sun.management.jmxremote.port=12345
> 
> -Dcom.sun.management.jmxremote.ssl=false
> 
> -Dcom.sun.management.jmxremote.authenticate=false
> 
> 
> With this implementation JMX exports JMX RMI connection objects exposed on
> a 'Random Port', meaning that for monitoring of a remote tomcat to
> be available, any firewall must allow access to all ports.
> 
> I would like to have the JMX RMI objects returned on a set port.
> 
> Do newer versions of tomcat address this issue, allowing me to set the port
> on which the JXM monitoring will respond.
> 
> Any information would be greatly appreciated

http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener

Mark

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

Re: servers @apache.org down ?

[Mark Thomas]

On 25/01/2012 15:31, André Warnier wrote:
> Hi.
> 
> Are they, or is it just me ?
> www.apache.org : not answering
> tomcat.apache.org : connection reset

Always check the Nagios monitoring site first:

http://monitoring.apache.org/status/

Any issues shown there are automatically sent to the appropriate infra
team members.

Mark

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

Re: servers @apache.org down ?

[Mark Thomas]

On 25/01/2012 16:44, Hassan Schroeder wrote:
> On Wed, Jan 25, 2012 at 8:28 AM, Mark Thomas  wrote:
> 
>>> tomcat.apache.org : connection reset
>>
>> Always check the Nagios monitoring site first:
>>
>> http://monitoring.apache.org/status/
> 
> ... though 'tomcat.apache.org' doesn't seem to be on that page ...

All tlp.a.o sites are virtual hosts on www.a.o

If www.a.o is down, they'll all be down.

Mark

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

Re: not able to access URL in 2nd app in 7.0.23

[Mark Thomas]

On 26/01/2012 03:59, removeps-c...@yahoo.com wrote:
>> When Tomcat receives an unauthenticated request for a protected
>> resource it intercepts and saves that request, then forwards to
>> the resource defined in the login config.
> 
> True.  Also, I'm not making the request through Firefox.  I did that
> below as part of my debugging only.
> 
> I have a Java application.  It calls
> 
> HttpsURLConnection.setFollowRedirects(false);
> 
> At some point it calls
> 
> HttpsURLConnection connection = (HttpsURLConnection)
> url.openConnection();
> 
> where url is "https://localhost:6143/myapp/folder/action.do";.  Then
> there is a call to
> 
> connection.setRequestMethod("POST");
> 
> along with the other usual methods for a post request.
> 
> T server intercepts this message and internally directs to
> /login.html.  Either a servlet should build this page or it should
> exist.  However, in 7.0.22 a POST request is made to this page,
> whereas in 7.0.23 a GET request is made.  Is this a bug in tomcat, a
> feature in tomcat, or required by the spec?

This is a design decision. The method used to request the login page
should always be GET regardless of what method was used to access the
protected page. This wasn't always the case and was corrected as part of
the fix for [1] in [2].

> Then the login.html page is generated and sent back to the client.
> 
> The client will then read this message and verify it is the expected
> login page.  The client will then send a post request to
> https://localhost:6143/myapp/j_security_check providing the username
> and password.

Whether POST or GET is used here will depend on the login page since it
is defined by the method attribute of the form element.

> At this point the server will authenticate, and if valid, will send
> 302 (redirect) with the URL as the page that was originally
> requested.
> 
> The Java client should now repeat the original post request.

The method to be used at this point is unclear to say the least. See
RFC2616 and the discussion on the handling of 302 redirects. Ideally,
this should be treated as a 303 redirect and a GET request issued.
Repeating the POST needlessly sends the request body again which Tomcat
will just silently swallow as it will restore the request body from the
original request.

Using a 303 in this case is under consideration for the next version of
the servlet spec.

Mark

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51940
[2] http://svn.apache.org/viewvc?view=revision&revision=1181030

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

Re: Tomcat 7 documentation weaknesses

[Mark Thomas]

On 26/01/2012 00:18, André Warnier wrote:
> Please see this this as a "constructive critic", not as a complaint.

Ack.

> The on-line documentation of Tomcat is not always easy-to-use,
> particularly when one is a relatively naive (or new) Tomcat user, and
> does not necessarily know what precise term to look for, or what belongs
> where.

Agreed.

> The main site www.apache.org does have a search box, but it uses Google
> (Eeek, a commercial outfit !)

So what? While the ASF has a preference for eating its own dog food
where possible, it also has zero problems with using (and paying for
where appropriate) commercial services even where an alternative open
source service exists if the commercial service is a better fit for the
problem at hand.

>, and its results are not always what one
> would expect, Tomcat-wise.

See https://issues.apache.org/bugzilla/show_bug.cgi?id=52235

> In the above, I may have missed some better links, but at least I think
> that they are not evident.

Patches welcome although some restructuring looks to be necessary as the
list how-to links has become quite long now.

> Does anyone feel like talking to the Apache Lucene people about some
> possible collaboration with the Apache Tomcat site ?

I think there are simpler fixes that can be applied first although
fundamentally what is required is a complete restructuring. I liked what
pid did with the Tomcat 7 start-up page. I'd love to see the whole
website and docs look something like that.

Some other references while I am here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=16579
https://issues.apache.org/bugzilla/show_bug.cgi?id=48672
https://issues.apache.org/bugzilla/show_bug.cgi?id=49122

Some requirements to keep in mind for the documentation pages:
- The source needs to be in svn
- The form that the edits are made in needs to be simple to work with
- We need to be able to generate the HTML as part of the build process
- The website and the docs should have the same look and feel (I'd be
happy if the old docs didn't)

Improving this comes down to someone having the time and the skills to
improve things. As always, volunteers welcome.

Mark

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

Re: servers @apache.org down ?

[Mark Thomas]

On 26/01/2012 09:59, André Warnier wrote:
> Seems to be down again, starting just 2 minutes ago.
> 
> Mark Thomas wrote:
>> On 25/01/2012 16:44, Hassan Schroeder wrote:
>>> On Wed, Jan 25, 2012 at 8:28 AM, Mark Thomas  wrote:
>>>
>>>>> tomcat.apache.org : connection reset
>>>> Always check the Nagios monitoring site first:
>>>>
>>>> http://monitoring.apache.org/status/
>>> ... though 'tomcat.apache.org' doesn't seem to be on that page ...
>>
>> All tlp.a.o sites are virtual hosts on www.a.o
> 
> Which itself does not seem to be on the above Nagios monitoring list
> right now..

Nagios checks once every 10 mins. Intermittent problems are expected
this morning while emergency maintenance (at our hosting location's
network provider) takes place to address yesterday's issues.

So in short, the ASF infra team knows about it but there is very little
we can do apart from wait for the problems to be fixed.

Mark

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

Re: ThreadLocals, context listeners and classloader leaks

[Mark Thomas]

On 26/01/2012 15:16, Patric Rufflar wrote:
>> I have no idea what the phrase "take the use of" means; what are you
>> trying to say?
> 
> I'd like to know if there's some statement from the tomcat team if the
> usage of ThreadLocals within contextInitialized() is discouraged or even
> not supported.

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

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

Re: Path of log files changed in Tomcat 7.0.25 when installing as Windows Service

[Mark Thomas]

On 27/01/2012 11:19, Konstantin Preißer wrote:
> Is this change intentional? Does that mean that I must any additional 
> environment variable like CATALINA_BASE?

It means you messed up your install. A clean install of 7.0.25 (with the
installer) works fine for me.

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 14:53, bxqdev wrote:
> Hello, Developers!
> 
> 1. What are the premises to use either
> apache.coyote.http11.Http11NioProtocol or
> org.apache.coyote.http11.Http11NioProtocol connectors?

There is no such protocol as "apache.coyote.http11.Http11NioProtocol" so
if you try using it, that connector will fail to start.

> 2. Do i get any advantages if i use Sync Servlet Api with
> Http11NioProtocol connector
Yes.

> or do i have to use Async Servlet Api to get
> the advantages?
No.

> 3. How do i choose which one to use in any particular case?
a) Understand your requirements
b) Read the docs, particularly [1]
c) Choose the connector that best meets your requirements.

Mark

[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison

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

Re: Not able to send reply for the post

[Mark Thomas]

On 27/01/2012 18:34, gnath wrote:
> Hi all, 
> 
> 
> Im not able to reply to some of my posts. I have been getting this failure 
> notice saying:
> :
> Remote
>  host said: 552 spam score (7.4) exceeded threshold 
> (FREEMAIL_FORGED_REPLYTO,FU_COMMON_SUBS2,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS
>  ) [BODY]
> 
> Is there any workaround or solution for this?

Stop sending e-mails in HTML format. Use plain text.

Mark

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

Re: Path of log files changed in Tomcat 7.0.25 when installing as Windows Service

[Mark Thomas]

On 27/01/2012 18:49, Caldarale, Charles R wrote:
>> From: verlag.preis...@t-online.de
>> [mailto:verlag.preis...@t-online.de] Subject: Re: Path of log files
>> changed in Tomcat 7.0.25 when installing as Windows Service
> 
>> So it seems the Tomcat logs are stored in 
>> "C:\tomcat7\bin\${catalina.base}\logs\", whereas the Daemon logs
>> are stored in "C:\tomcat7\logs\".
> 
> I've duplicated the problem on Windows 7 64-bit as well as XP when
> using service.bat.  Haven't yet figured out why the ${catalina.base}
> references in logging.properties aren't getting resolved.

That'll be a bug then. Please create a bugzilla entry. If you find the
root cause as well, that would be great. A patch would be even better ;)

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 21:03, bxqdev wrote:
> 
> 
> On 1/27/2012 8:29 PM, Mark Thomas wrote:
>> On 27/01/2012 14:53, bxqdev wrote:
>>> Hello, Developers!
>>>
>>> 1. What are the premises to use either
>>> apache.coyote.http11.Http11NioProtocol or
>>> org.apache.coyote.http11.Http11NioProtocol connectors?
>>
>> There is no such protocol as "apache.coyote.http11.Http11NioProtocol" so
>> if you try using it, that connector will fail to start.
> 
> i assume you can guess that it's org.apache.coyote.http11.Http11NioProtocol

In which case they are identical since you are specifying the same class
name.

>>> 2. Do i get any advantages if i use Sync Servlet Api with
>>> Http11NioProtocol connector
>> Yes.
> 
> What are they?

As per the docs. You even quoted the comparison.

>>> 3. How do i choose which one to use in any particular case?
>> a) Understand your requirements
>> b) Read the docs, particularly [1]
>> c) Choose the connector that best meets your requirements.
> 
> it's a bit abstract.

I suspect you need to read up (generally) on the differences between
blocking and non-blocking IO.

>Java Blocking Connector   Java Nio Blocking
> Connector
>  BIO NIO
> Classname  Http11Protocol Http11NioProtocol
> Tomcat Version   3.x onwards 6.x onwards
> Support Polling  NO  YES
> Polling Size N/A   maxConnections
> Read HTTP Request Blocking  Non Blocking
> Read HTTP BodyBlocking  Sim Blocking
> Write HTTP Response   Blocking  Sim Blocking
> Wait for next Request Blocking  Non Blocking
> SSL Support   Java SSLJava SSL
> SSL Handshake Blocking  Non blocking
> Max ConnectionsmaxConnections  maxConnections
> 
> It doesn't show how that corresponds to Sync vs Async Servlet APIs.

Because there is no correlation.

> actually it's interesting to know about the following cases:
> 1. Sync Servlet  + Non Bloking NIO Connector
> 2. Async Servlet + Bloking IO Connector

Know what? They both work. How well they work will depend on many
factors outside of Tomcat's control.

> How are connector and servlet code related?

Again, read the docs:
http://tomcat.apache.org/tomcat-7.0-doc/architecture/requestProcess/requestProcess.pdf

It is slightly old and probably not completely correct in all details
for 7.0.x but should be good enough.

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 21:31, bxqdev wrote:
> 
> On 1/28/2012 1:14 AM, Mark Thomas wrote:
>> On 27/01/2012 21:03, bxqdev wrote:
>>>
>>>
>>> On 1/27/2012 8:29 PM, Mark Thomas wrote:
>>>> On 27/01/2012 14:53, bxqdev wrote:
>>>>> Hello, Developers!
>>>>>
>>>>> 1. What are the premises to use either
>>>>> apache.coyote.http11.Http11NioProtocol or
>>>>> org.apache.coyote.http11.Http11NioProtocol connectors?
>>>>
>>>> There is no such protocol as
>>>> "apache.coyote.http11.Http11NioProtocol" so
>>>> if you try using it, that connector will fail to start.
>>>
>>> i assume you can guess that it's
>>> org.apache.coyote.http11.Http11NioProtocol
>>
>> In which case they are identical since you are specifying the same class
>> name.
> 
> oh, i see. well, nio or io connectors. that's what i mean.

There is no "IO" connector. Tomcat 7 supports three connector variants:
BIO, NIO & APR/native. There are separate implementations of each for
the HTTP and AJP protocols.

>> I suspect you need to read up (generally) on the differences between
>> blocking and non-blocking IO.
> 
> i know the differences.

Then why are you asking such basic questions about the differences
between non-blocking IO and blocking IO?

> but it looks like there's 2 points of choice:
> 1. nio vs. io in connectors
> 2. nio vs. io in servlet api

There is no NIO support in the Servlet spec. The Servlet API uses
entirely blocking IO throughout.

There is Async support in Servlet 3.0 onwards which could be viewed as a
form of non-blocking IO I guess but is really just a way to de-couple
writing to the response and the thread processing the request/response pair.

> i don't understand how this choices are related.

They aren't. If you want to understand what Servlet 3.0 async is, you
need to read the Servlet 3.0 spec.

>>> How are connector and servlet code related?
>>
>> Again, read the docs:
>> http://tomcat.apache.org/tomcat-7.0-doc/architecture/requestProcess/requestProcess.pdf
>>
> 
> i will. didn't know about the existence of that document.
> 
>>
>> It is slightly old and probably not completely correct in all details
>> for 7.0.x but should be good enough.
> 
> that's bad. maybe you could explain in few words, as an expert?

No fundamental changes. Replace thread pools with executors and the
detail of the Protocol / Processor / Endpoint relationships (which is
important to understand as soon as you starting working with the code)
isn't shown but you don't really need that. Also, the Async behaviour
isn't shown.

Mark

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

Re: upgrading tomcat when installed via apt-get

[Mark Thomas]

On 27/01/2012 21:41, S Ahmed wrote:
> If I need to upgrade an existing live application that is running off a
> tomcat install that was installed via apt-get (ubuntu), how would I go
> about updating tomcat?

Don't know. That would be a question for an Ubuntu support forum.

> I would have to understand exactly how tomcat is installed correct?  i.e.
> things like xml conf files, symbolic links to paths that may have been
> created, startup/stop scripts that might need to point somewhere else etc.
> 
> Am I making this too complicated or is this how others update to a newer
> version of tomcat?

It depends. It isn't how I do it. I use separate CATALINA_HOME and
CATALINA_BASE. Upgrades and downgrades are then trivial. For example,
upgrading the ASF's Jira instances takes less than 2 minutes and most of
that time is waiting for Jira to shutdown and startup.

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 22:22, bxqdev wrote:
> ok, so what about this case:
> http nio  connector + async servlet
> i would say that in this variant there're 2 points of asynchronism -
> both connector and servlet code are async.
> is there a case when i would need such a combination?

Where someone might need that? Sure. Where you would need it? No idea.
My crystal ball is looking rather foggy at the moment. If you have a
specific question about a specific use case...

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 22:41, bxqdev wrote:
> 
> 
> On 1/28/2012 2:28 AM, Mark Thomas wrote:
>> On 27/01/2012 22:22, bxqdev wrote:
>>> ok, so what about this case:
>>> http nio  connector + async servlet
>>> i would say that in this variant there're 2 points of asynchronism -
>>> both connector and servlet code are async.
>>> is there a case when i would need such a combination?
>>
>> Where someone might need that? Sure. Where you would need it? No idea.
>> My crystal ball is looking rather foggy at the moment. If you have a
>> specific question about a specific use case...
> 
> so can i say that:
> 1. if one needs to decouple client from nio server (tomcat-7), nio
> connector can be used to solve that.

Define "decouple".

> 2. async servlet api is not much usefull for servers, with nio
> connectors (tomcat-7). at least you can't image the case.

I don't say that. In fact, I said exactly the opposite.

> 3. async servlet api is some general technology to decouple client from
> server, when server doesn't have nio connector (server is bio-only).

No. The Servlet Async API and the considerations for when one might use
it are completely orthogonal to connector selection.

I am getting rather bored with this. Please go and read up on blocking
IO vs. non-blocking IO and then read the Async parts of the Servlet 3.0
specification. Then come back here and try asking some more focussed
questions.

Mark

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

Re: Connectors: Http11Protocol vs. Http11NioProtocol

[Mark Thomas]

On 27/01/2012 23:16, bxqdev wrote:
>>> 2. async servlet api is not much usefull for servers, with nio
>>> connectors (tomcat-7). at least you can't image the case.
>>
>> I don't say that. In fact, I said exactly the opposite.
> 
> well, then what's the case to use both of this technologies? can you
> make up a theoretical case for an example?

Yes. See below.

>>> 3. async servlet api is some general technology to decouple client from
>>> server, when server doesn't have nio connector (server is bio-only).
>>
>> No. The Servlet Async API and the considerations for when one might use
>> it are completely orthogonal to connector selection.
> 
> how is that? both connector and servlet process user http request. one
> by one. how are they orthogonal?

The Servlet API, including the Async API only provides blocking IO.

I will ignore the APR/native connector since that just complicates
things further and just consider the BIO and NIO connectors below.

The fundamental difference is that BIO requires one thread per
connection whereas NIO requires one thread per currently processing
request plus a few threads for the pollers. Each poller can monitor
several thousand connections.

Therefore in a situation where you have many more connections than you
have current requests (think lots of HTTP keep-alive) then NIO scales
significantly better than BIO. The (very small) price you pay is
performance since using a poller adds overhead to request processing.

[1] shows that the NIO connector uses non-blocking IO where it can but
as soon as it enters the realm of the Servlet API (reading the request
body and writing the request response) it has to simulate blocking IO.

There is actually a complication to BIO in newer versions of Tomcat.
Rather than dedicating one thread to a connection, each time Tomcat
needs to read from a connection (remember this is blocking IO and there
might not be anything to read if the connection is in keep-alive but the
thread will then block until some data turns up or the connection times
out) Tomcat obtains a thread from an executor. This raises the
possibility of having more connections than you have threads. With BIO
that is usually bad and results in unexpected delays in processing
requests but as we'll see shortly, there are times (not many) where it
might be useful.


Prior to the Servlet 3.0 Async API a single container thread was
responsible for all of the processing associated with a request.

A few points to note at this point:
- All IO is still blocking IO
- The async API is only for writing data to the response. There is no
"async" reading of data from the client.

A typical usage of the Servlet 3.0 Async API is as follows:
- request processing starts as usual on a container thread
- async is started
- the container thread is returned to the container's thread pool
- processing continues on an application thread
- the application writes some data to the response
- the application passes the response back to the container for the
container to finish it off on a container thread

The purpose of the Servlet 3.0 Async API is to remove the one thread per
currently processing request constraint.

This allows applications to do things like:
- implement a stock ticker with one thread writing to many responses
(rather than one thread per response)
- implement a chat program with one thread writing to all the clients
(rather than one thread per response)

If applications relay on external resources that are known to take a
long time to respond, prior to the Async API developers had no choice
but to simply block waiting for the external resource to respond. With
the Async API, a single thread can monitor an external resource on
behalf of many requests and only dispatch the request/response pair to a
container thread for processing when the external resource has replied.
This allows for more efficient use of container threads.

Now back to the BIO complication. Lets say you have 100 container
threads configured on your BIO connector and you are absolutely sure
that at any one time 20% of your incoming connections would be using
Servlet 3 Async and would be being handled by an application thread then
you could set maxConnections to 120 and service 120 users in parallel.
Your assumption regarding the 20% was wrong then you would see
potentially long delays in processing incoming requests as connections
with data were waiting for a container thread to become available to
process it.


So back to my original point. BIO vs NIO and Servlet 3 Sync vs Async are
solving orthogonal problems.

If you use an NIO connector that doesn't help you write a chat
application more efficiently. You would still need one thread per
client. For that you need the Servlet 3.0 Async API.

The Async API does not help you efficiently handle many thousands of
connections when the majority of them are in HTTP keep-alive. For that
you need the NIO connector.

Different problems, different solutions.

>> I am getting rather b

Re: Tomcat 6 - How to make an application available at www.mydomain.com

[Mark Thomas]

On 29/01/2012 11:06, Pid wrote:
> On 29/01/2012 03:42, Caldarale, Charles R wrote:
>>> From: Dean Del Ponte [mailto:dean.delpo...@gmail.com] Subject:
>>> Tomcat 6 - How to make an application available at
>>> www.mydomain.com
>> 
>>> How can I make this application available at
>>> "http://www.mydomain.com"; without deploying it as ROOT.war?
>> 
>> Just save yourself much grief and go ahead and deploy it as
>> ROOT.war - follow best practice.
> 
> +1  A trivial example: if someone else who doesn't understand the
> config administers the server in future and inadvertently places a
> ROOT.war file in the appBase...
> 
> If, for some reason, you really, really need to see what the
> application is called, then consider upgrading to Tomcat 7.0 and
> using the parallel deployment feature.  Then you can name your
> application:
> 
> ROOT##my-important-app-name-1.0.war
> 
> The whole of the section after ## is considered to be part of the 
> version identifier.  I think this is a much better way of
> addressing the usual argument about naming & leaves the application
> layout on the file system easy to understand.

Genius. I love it.

Mark

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

Re: [OT] problems with performance with IIS 7.5 and Tomcat Connector

[Mark Thomas]

On 02/02/2012 09:57, André Warnier wrote:
> Alex Samad - Yieldbroker wrote:
>> Hi
>>
>>
>>
>> Hopefully this is the right list :)
> 
> Actually I don't know, but I would also like to know.
> I have noticed previously on this list, that whenever someone mentions
> JBoss, some of the people here (Tomcat developers ?)

In the most recent case, it was a JBoss/Tomcat developer who responded.

> seem to react quite
> strongly, and tell the poster curtly to go ask their question on the
> JBoss support list.
> 
> On the other hand, it seems to be so that JBoss is a server software
> which uses Tomcat as the underlying servlet engine. (But maybe also I am
> mistaken there, I do not really know JBoss).

JBoss used to embed Tomcat directly. Some time ago (before Tomcat 7 -
Remy would know exactly when) JBoss opted to fork Tomcat. I believe (I
haven't looked) that the code bases remain similar in many areas but
there are some significant differences. For example, the Servlet 3
implementations are likely to be very different.

I don't see any issue with JBoss questions here up to the point that it
is apparent that the issue is in an area where the JBoss fork has
diverged. Then the JBoss support forums would be a better place to seek
help.

> In any case, there seems to be more to it than meets the eye of the
> naive subscriber that I am. So it would be nice if someone here provided
> some clarity on the matter.

The above is the best I can do short of doing a diff between the JBoss
code and Tomcat code.

> Anyway, from your description of the matter and of the configuration
> files, it seems that your question is at least to a large extent related
> to the isapi_redirect IIS plugin, which is developed by some of the
> people on this list, and thus for which this list is the right place for
> your questions, as far as I know.

+1.

Mark

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

Re: [OT] problems with performance with IIS 7.5 and Tomcat Connector

[Mark Thomas]

On 02/02/2012 20:19, Bilal S wrote:
> I am willing to learn but finding the Apache related processes
> singularly difficult to deal with. We are working with mailing list,
> in the age of websites and social media.

Correct. This is deliberate. Mailing lists are the lowest common
denominator and allow the widest possible participation. Not everyone
has an always on internet connection with high bandwidth. For those
folks with bandwidth to spare that prefer a forum interface, there are
third parties that provide it. I love that the tools we use at the ASF
work just as well when I (or anyone else) is at the end of a very slow
mobile data connection in the middle of almost nowhere even though
trying to view a web page from the same place is pretty much impossible
these days.

> There is no easy to find contact form anywhere on the Apache
> websites.

Also correct. The primary form of communication within Apache
communities are the mailing lists and these should be obviously linked
from each project's home page. In Tomcat's case, you'll find the forum
based interfaces linked from the same place.

> Yet, there seems to be a lot emotions floating around in this list.

With a high a volume mailing list such as this, there is an expectation
that folks follow [1] and a distinct lack of patience for folks that
continue to ignore that excellent advice after they have been pointed
towards it.

> This in  a way is good. It speaks of passion and dedication. I would 
> ask that this passion is directed toward assistance and innovation.
> This probably will go farther than anything else.
> 
> Feel free to email me directly if you want to chat.

Off-list communication is discouraged. This is a single community that
communicates through the project mailing lists. This is particularly
important on the dev list. A key element of the "Apache Way" is:
"If it didn't happen on the list, it didn't happen".

Mark

[1] http://catb.org/esr/faqs/smart-questions.html

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

Re: Can a separate web application have a separate memory pool

[Mark Thomas]

On 05/02/2012 23:19, Josh Gooding wrote:
> Hey guys,
> 
> In .net can you run your application in a shared pool or it's own pool on
> the IIS server, so it doesn't bring down the entire server in the event of
> a OOM error.  Does Tomcat allow you to do this as well?

No.

>  So you can
> basically segregate each application to it's own pool of memory in the
> server.  I updated the servers at work to 6.0.35.  It runs SOOO much faster
> and better, but there is still an application that is doing something funky
> and causing OOM's and that halt's the entire server.  I DID set the initial
> memory pool to 512 and it's max pool to 1532 (1.5GB) but this application
> (yes while poorly written and horribly outdated) is crashing the entire
> server.

Just run the broken app in a separate Tomcat instance.

Mark

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

Re: tomcat 7.0.25 - tomcat7 //US//.... ++jmvOptions broken ??

[Mark Thomas]

On 06/02/2012 04:53, Caldarale, Charles R wrote:
>> From: Dan Tran [mailto:dant...@gmail.com] 
>> Subject: Re: tomcat 7.0.25 - tomcat7 //US// ++jmvOptions broken ??
> 
>> it seems procrun already fixed this issue at its end.
> 
> Only in SVN, no new commons-daemon releases yet.
> 
>> does tomcat team has a tentative schedule date for 7.0.26?
> 
> Usually about once a month, and the last one was 21 January.  You can apply 
> the workaround here while you're waiting:
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52548

I've been a little slower on the releases the last few months. The aim
is still once a month but I don't always make it.

Mladen has proposed a Commons Daemon release later this week. Once that
completes I'll pull it into 7.0.x and start looking at a 7.0.x release.

Mark

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

Re: Serving static content using embedded tomcat 7

[Mark Thomas]

On 08/02/2012 08:40, sanu wrote:
> Thank you. 
> 
> I just did that. Here's what I have :
> 
> StandardContext context = (StandardContext)
> tomcat.addContext(null, "",  directory");
> 
> This doesn't seem to work.

You haven't told us:
- exact Apache Tomcat version
- what the path to the resources is
- how the other contexts are referring to these resources

In addition to answering the questions above, I'd strongly recommend
reading [1]. It will help you write better questions which in turn will
get you more useful answers.

Mark

[1] http://catb.org/esr/faqs/smart-questions.html

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

Re: Why am I Getting org.apache.catalina.realm.JDBCRealm getPassword SEVERE: Exception performing authentication?

[Mark Thomas]

On 08/02/2012 18:23, Jonathan Rosenberg wrote:
> Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
> The last packet successfully received from the server was 58,153,867
> milliseconds ago.  The last packet sent successfully to the server was
> 58,153,867 milliseconds ago. is longer than the server configured
> value of 'wait_timeout'. You should consider either expiring and/or
> testing connection validity before use in your application, increasing
> the server configured values for client timeouts, or using the
> Connector/J connection property 'autoReconnect=true' to avoid this
> problem.

Which part of this is unclear?

Mark

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

Re: Why am I Getting org.apache.catalina.realm.JDBCRealm getPassword SEVERE: Exception performing authentication?

[Mark Thomas]

On 08/02/2012 19:15, Jonathan Rosenberg wrote:
> On Wed, Feb 8, 2012 at 1:41 PM, Mark Thomas  wrote:
>> On 08/02/2012 18:23, Jonathan Rosenberg wrote:
>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
>>> The last packet successfully received from the server was 58,153,867
>>> milliseconds ago.  The last packet sent successfully to the server was
>>> 58,153,867 milliseconds ago. is longer than the server configured
>>> value of 'wait_timeout'. You should consider either expiring and/or
>>> testing connection validity before use in your application, increasing
>>> the server configured values for client timeouts, or using the
>>> Connector/J connection property 'autoReconnect=true' to avoid this
>>> problem.
>>
>> Which part of this is unclear?
> 
> The message is, indeed, perfectly clear. Did you read my post?
> 
> I don't understand why Tomcat is involved in the authentication  (the
> exception happens in org.apache.catalina.realm.JDBCRealm getPassword)
> at this point.  As far as I know, the only authentication going on
> should be the CAS authentication used by my app.

> SEVERE: Exception performing authentication
> com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
> No operations allowed after connection closed.Connection was
> implicitly closed by the driver.
>at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
>at com.mysql.jdbc.Util.getInstance(Util.java:384)
>at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015)
>at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:989)
>at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984)
>at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:929)
>at
com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.java:1193)
>at com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3035)
>at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1612)
>at
org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579)
>at
org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408)
>at
org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355)
>at
org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:146)
>at
org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:180)
>at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:157)

This means you are using Tomcat's BASIC authentication.

It appears you do not have CAS configured correctly. Check your web.xml.

Mark

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

Re: Why am I Getting org.apache.catalina.realm.JDBCRealm getPassword SEVERE: Exception performing authentication?

[Mark Thomas]

On 08/02/2012 19:52, Jonathan Rosenberg wrote:
> Mark,
> 
> Thanks for the reply.
> 
>>> I don't understand why Tomcat is involved in the authentication  (the
>>> exception happens in org.apache.catalina.realm.JDBCRealm getPassword)
>>> at this point.  As far as I know, the only authentication going on
>>> should be the CAS authentication used by my app.
> 
>> This means you are using Tomcat's BASIC authentication.
>> It appears you do not have CAS configured correctly. Check your web.xml.
> 
> I'm (obviously) a novice here.  Which web.xml should I be checking?
> 
> - The app's web.xml? (There is mention of anything security-related there).
>
> - The 'root' web.xml?

Ah. The joy's of debugging Servlet 3.0 applications. Web fragments were
such a good idea. Not.

In CATALINA_BASE/conf/context.xml, add the following to the  element:

logEffectiveWebXml="true"

That will cause Tomcat to log the result of merging the default web.xml,
host level web.xml, app level web.xml, web fragments and annotations as
an 'effective' web.xml file. Then look at your app for the CAS config
and and  sections.

> Is there any easy way to tturn on logging for Tomcat's authentication?

I don't think that is going to help much right now.

Mark

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

Re: Path parameters and getRequestURI

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/02/2012 20:35, Christopher Schultz wrote:
> All,
> 
> There was a change in 6.0.33 (and it has always been the case in 
> 7.0.x?) that HttpServletRequest.getRequestURI now returns path 
> parameters as part of the URI. That notably includes the
> URL-encoded jsessionid that Tomcat uses when the availability of
> cookies on the client is set to be determined.
> 
> I have a Filter that checks to see if the user is accessing a 
> particular set of predefined pages and redirects them if they
> don't hit any of them.
> 
> Needless to say, without any changes to my code, anyone who hits
> this filter who either has cookies disabled or is in the middle of
> an authentication ritual that redirects to the original page is
> going to have a problem.
> 
> Is it safe to simply remove everything after the initial ";" if
> I'm not interested in any path parameters? I don't want to just
> trim-off that kind of thing blindly if there are any gotchas that I
> should be aware of.
> 
> Can anyone think of a reason I can't just do that?

Yes. Path parameters can occur at any part of the path.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPMt0XAAoJEBDAHFovYFnnqwwP/0rOF5jJeEXWT3CToOgah8hq
gSmRy8fnUbOPIwJlc66Y4M8zv8dRmu2XmY5zfNL+G8QshzV3Bxwg5hK1PssHjMcF
eeyYuafVO7N2GgkqiC/9wnuhjSdijCWCWDNT8PMcAJh64vj+NEJ8Qq3EGwv4rbyq
GT6oXevwayzskYMm+F/QdUBj/APDMiMfwGd0GzcdcRbaW5s5zVtHHofqAJ3u2txQ
iCobCSMlf8/Vqm3CBCHJSUvQDLC7V0B4Imd4J77bg3Cmh+buIBFzKJeZHQdKSIui
dUgouT7IHYtSChkxcf3yBuIkZQYJk4i/qHIrGmWslU1c5G3I1O/3lJuucXDsj/3V
ZWTx4dvedywk3RjtJBEb21Q3q+buWx66+4mqpuHKW2TJlsh0S/hjC4k+Yiw71Xa+
qHWdodS5WCvsaJConMUdlTk+MHYQAXf3iqygYNm3PwrGmgLO2zFpnqdF3mQNIbwR
ZhgtxRpkIXZvmeq2jykZzLk9rDIoXp3bhd7/NO5lYzgc2CLZNp5atfmT6WbPUiWc
YmF2jqhpTkK4L32Y0989XMcNhUg5Lil/YoAPjuOcNhPB0ax47LgSOJiV7Et+0TjK
iSJsAlhBFJhI/whWCo6LHZ2al5wOOolFJD+H/x7F4vmr7UfvxnSOhg67o1pcxrb8
cFVd0+BfBkE8hcmOOjs5
=d1RU
-END PGP SIGNATURE-

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

Re: Path parameters and getRequestURI

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/02/2012 21:25, Christopher Schultz wrote:
> Mark,
> 
> On 2/8/12 3:37 PM, Mark Thomas wrote:
>> On 08/02/2012 20:35, Christopher Schultz wrote:
>>> Can anyone think of a reason I can't just [chop-off everything
>>>  after the first ";"]?
> 
>> Yes. Path parameters can occur at any part of the path.
> 
> So a URI could look like this:
> 
> /context/something;p1=val;p2=val/morestuff

Yes.

> ... and that URI would match /context/something/morestuff as a 
> uri-pattern for, say, filter or servlet mappings?

Yes, as per section 12.1 of the 3.0 servlet spec (and equivalent in
earlier versions).

> Does Tomcat attempt to ignore path parameters when going these
> types of matches? (I'd read the code, but the mapper is, as you
> know... complex).

The real trick is knowing that you don't need to look at the mapper
code :). Of course, it helps if you remember that you wrote the code
in question ;) Take a look at CoyoteAdapter#parsePathParameters()

> Path segments are separated by / characters, so perhaps I could
> adjust my "ignore the path parameters" algorithm to work like
> this:
> 
> Starting from the end of the URI, rewind until I hit a "/", then
> go forward until I hit a ";", then trim forward from the ";".

They can also be on the final path segment (and usually are).

> Or, I could just say "ignore anything like 
> ';jsessionid=[0-9A-Za-z]*'", but that's a little presumptuous and 
> potentially fragile as well.

Indeed.

Unfortunately, the servlet spec is far from clear on how path
parameters should be handled. I hope to get clarity in 3.1 with [1]

Mark

[1] http://java.net/jira/browse/SERVLET_SPEC-18

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPMupgAAoJEBDAHFovYFnnmSYP/2lFZ3r6d1t8o+HnoEfHFYqj
X5ycDq+75DHrX/thLjoQzfYF1BxhtiimEnSJDW+bXgMLC/5dEh10VtE2vpMgh9PX
CxNELhtJ5jFezSPSaqH9lh9L+2v6sCqFM9F4KOuSk3dU+bWenBhqwE8dYxspITU6
KnsXjvYKUnl7pI867eTQji0I3uPnirW5s/RkFKY4YIPtkTniCfwF8Z+x7s6tylOQ
fcWUcT5w3WDsWTnkNxcIngqvAYDMM7olHrS7DToU8RXmd8/8yEpVXyfCS2Ftu5zI
0VzFuYpas9TOOB0Ke6uEwtQvZ1kUbUfwpB4DoUv6iXrLr9sMUufzzAYhV2kC0uOY
++8XaFzGc9jxAZiuJrRpWDF1OuXAvTXbKjVFKY4PSvEZZEofAJbMgPtAcA+IFjVg
VaZzMl68rvzsId7WAzMRhHrNZJl+SvJ1T/z1lrjqyNNuXg6o0eVLSZkvy7QbJ7BR
cPGhCq7YQ7QpqAUOu4xUhPmET0eoCtBgcc9gGiS0oUT4OQKmqfQC3BVUmSJ9eJy9
qYkBTfqVqLXn7YL5XW3U0V/d+J6rZGXHZhhr1Sr0PPXG2vC0fk2w+wJy2JyznWOa
sZlHEddZ5OmxXNnUlQuZSas1hLGcKUCQre3f74KV0Q/ULoa1Kp+xq0+B9XZnvVYH
aT9fN7DspB9aP1mui/GL
=Iwkm
-END PGP SIGNATURE-

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

Re: JmxRemoteLifecycleListener binding to all IP addresses

[Mark Thomas]

On 09/02/2012 15:35, Jesse Farinacci wrote:
> What is the expected behavior? Is this a bug?

The expected behaviour is as you describe.

No it is not a bug.

Being able to specify the bind address is an enhancement request that
doesn't look too difficult to implement (and would remove the need for
the useLocalPorts attribute since localhost / 127.0.0.1 / ::1 could be
specified as the host name / address).

Mark

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

Re: Cores with FlushableGzipOutputStream

[Mark Thomas]

On 09/02/2012 20:07, Allen Reese wrote:
> Try again now that I'm subscribed.

If libzip.so is provided by the JVM installer (and I think it is) then
it is still a JVM problem. See [1] for an example where Oracle did
accept that an crash in libzip.so was a bug.

All changing the Tomcat code indicates is that some paths trigger the
bug and some don't. That does not absolve the JVM of responsibility.

Mark

[1] http://bugs.sun.com/view_bug.do?bug_id=6866479

> 
> 
>> -Original Message-
>> From: Allen Reese
>> Sent: Thursday, February 09, 2012 12:03 PM
>> To: 'users@tomcat.apache.org'
>> Cc: Lars Anderson
>> Subject: Cores with FlushableGzipOutputStream
>>
>> We've just upgraded from tomcat 6.0.33 to 6.0.35 and started having the
>> JVM core on our production boxes.
>>
>> I'm trying to determine what the next course of action should be here.
>> I have an Oracle Support contract, but they don't seem to see this as a
>> JVM issue, and blame it on a native lib.
>>
>>
>> Thanks.
>>
>> Allen Reese
>> Core Platforms
>> Yahoo!, Inc.
>>
>> Running on linux x86-64, jdk 6u27, 6u29, 6u30, 7u2
>>
>> We run several tests and the output is:
>>
>> Jdk  | Version   | flags
>>  |
>> 6u30 | 6.0.33| compression enabled
>>  | works
>> 6u30 | 6.0.35| compression enabled
>>  | cores
>> 6u30 | 6.0.35| compression disabled
>>  | works
>> 6u30 | 6.0.35| Remove changes to FlushableGzipOutputStream [1]
>>  | works
>> 6u30 | 6.0.35| -Dsun.zip.disableMemoryMapping=true
>>  | cores
>>
>> 7u2  | 6.0.35| compression enabled
>>  | cores
>> 7u2  | 6.0.35| compression disabled
>>  |
>> 7u2  | 6.0.35| Remove changes to FlushableGzipOutputStream [1]
>>  |
>> 7u2  | 6.0.35| -Dsun.zip.disableMemoryMapping=true
>>  | cores
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52121
>>
>> I filed an SR with Oracle, as this looks like a JVM bug and got the
>> following response:
>>
>> Generic Note
>> 
>> Hi Allen,
>>
>> Thank you for sending the hotspot error logs (hs_err_pid). Each
>> one of them has verbiage that indicates the problem is not with Java,
>> but with native code:
>>
>> # Problematic frame:
>> # C [libzip.so+0x77e3] char+0xa3
>> #
>> # If you would like to submit a bug report, please visit:
>> # http://java.sun.com/webapps/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>>
>> The case description also noted:
>>
>> Rolling back this patch to tomcat increases stability:
>> http://svn.apache.org/viewvc?view=revision&revision=1197382
>>
>> Again, this points to software other than Java. The Java defect
>> mentioned, 4813885, was fixed in June of 2009.
>> =
>>
>> Allen Reese
>> Core Platforms
>> Yahoo!, Inc.
>>
>> [1]: Patch to remove changes to FlushableGZIPOutputStream from 6.0.35.
>>
>> --- apache-tomcat-6.0.35-
>> src/java/org/apache/coyote/http11/filters/FlushableGZIPOutputStream.jav
>> a2011-11-28 02:22:45.0 -0800
>> +++ apache-tomcat-6.0.33-
>> src/java/org/apache/coyote/http11/filters/FlushableGZIPOutputStream.jav
>> a2011-08-16 05:26:14.0 -0700
>> @@ -35,93 +35,58 @@
>>  super(os);
>>  }
>>
>> +private static final byte[] EMPTYBYTEARRAY = new byte[0];
>> +private boolean hasData = false;
>> +
>>  /**
>> - * It is used to reserve one byte of real data so that it can be
>> used when
>> - * flushing the stream.
>> + * Here we make sure we have received data, so that the header has
>> been for
>> + * sure written to the output stream already.
>>   */
>> -private byte[] lastByte = new byte[1];
>> -private boolean hasLastByte = false;
>> -
>> -@Override
>> -public void write(byte[] bytes) throws IOException {
>> -write(bytes, 0, bytes.length);
>> -}
>> -
>>  @Override
>> -public synchronized void write(byte[] bytes, int offset, int
>> length)
>> +public synchronized void write(byte[] bytes, int i, int i1)
>>  throws IOException {
>> -if (length > 0) {
>> -flushLastByte();
>> -if (length > 1) {
>> -super.write(bytes, offset, length - 1);
>> -}
>> -rememberLastByte(bytes[offset + length - 1]);
>> -}
>> +super.write(bytes, i, i1);
>> +hasData = true;
>>  }
>>
>>  @Override
>>  public synchronized void write(int i) throws IOException {
>> -flushLastByte();
>> -rememberLastByte((byte) i);
>> +super.write(i);
>> +hasData = true;
>>  }
>>
>>  @Override
>> -public synchronized void finish() throws IOException {
>> -try {
>> -flushLastByte();
>> -} catch (IOException ignore) {
>> -// If our write failed, then trailer write in finish()
>> will fail
>> -// with IOExce

Re: mod_jk and URL rewriting/proxying?

[Mark Thomas]

On 09/02/2012 20:18, Caldarale, Charles R wrote:
>> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Subject:
>> RE: mod_jk and URL rewriting/proxying?
> 
>> does one still have to modify the server.xml if we want new hosts 
>> to be there the next time we restart tomcat?
> 
> A brief scan of the code indicates that you will have to maintain
> server.xml yourself.  All I could see was code that manipulates the
> active objects; nothing seems to be persisted.

Correct. There was some code that tried to do this back in 5.5.x but it
was buggy, not maintained and therefore got dropped.

Mark

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

Re: programmatically determining connector startup failures

[Mark Thomas]

On 10/02/2012 15:38, Erick Lichtas wrote:
> Hi everyone,
> 
> I'm using tomcat 6.0.32 on Windows 7.  I have an application where I
> programmatically start and stop a separate web application from
> within an already running tomcat application.  I do this by creating
> a new StandardService, setting the server as
> service.setServer(ServerFactory.getServer()) and creating/loading the
> connectors, engine, etc... all before calling service.start() to fire
> everything up.
> 
> Everything is working great, but I'm running into a small snag.
> Should a connector of the service run into issues such as binding to
> a port, the StandardService.start() seems to swallow the exception.
> It gets logged, but my caller to service.start() has no way handling
> that failure.
> 
> StandardService.java (~line 539) try { ((Lifecycle)
> connectors[i]).start(); } catch (Exception e) { 
> log.error(sm.getString( "standardService.connector.startFailed", 
> connectors[i]), e); }
> 
> I've also looked into registering a LifecycleListener on the
> connector, but that doesn't won't tell me whether or not the start
> had completed.

connector.isAvailable() ?

> Are there any other options, other than extending and for the most
> part duplicating the StandardService class, that might give me the
> ability to detect a failed connector startup?

Upgrade to 7.0.x where all this was completely re-written?

Mark

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

Re: EL String -> int coercion stopped working after TC 5.5 -> 7.0 upgrade?

[Mark Thomas]

On 14/02/2012 03:11, David Rees wrote:
> This may not be Tomcat related, but I couldn't find anything in the
> JSP/JSTL/EL specifications regarding a change in behavior from JSP
> 2.0-2.2.
> 
> Here's a simple JSP 2-line which shows the issue:
> 
> <%@taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c"%>
> 
> 
> Using Tomcat 5.5.35 the page will print true for any value of foo
> which converts to an integer:  1, 01, 001, etc.
> 
> Using Tomcat 7.0.25 the page will only print true if foo is 1.  01
> will result in false.
> 
> Am I missing something or is this a bug in Tomcat 7?  I haven't tested
> with TC6 yet.

I check of the relevant specifications indicates that, unless I missed
something obvious, the 5.5.x behaviour is correct and should be
unchanged in 7.0.x.

Initial impressions are that this is a bug. That said, the coercion
rules are quite strict and 7.0.x is better at following them. Debugging
through the code may identify that the problem lies elsewhere.

Mark

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

Re: Cores with FlushableGzipOutputStream

[Mark Thomas]

On 16/02/2012 20:45, Allen Reese wrote:
> My question is, I have all of the data in pcap format, so I can extract the 
> chunks, what is the best way to feed this through.
> Do I decompress it all and write it all at once through the stream?
> Or is this going to matter based on what order the chunks got written in.

Based on the work we did on the previous JVM bug that we worked around,
you'll need to flush at the correct point. I would start by recreating
exactly what you see in the network trace and then start to merge chunks
to simplify as far as you can.

Mark

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

Re: Free Memory vs. Total Memory vs. Max Memory

[Mark Thomas]

On 18/02/2012 14:44, Mark Thomas wrote:
> "Robinson, Eric"  wrote:
> 
>> Agreed. Anyway, in this case the thread is on a tomcat server that
>> is only used for scheduled java tasks. Users do not access it
>> directly. Very puzzling. What's I'd really like is for some
>> well-known tomcat guru to say that in our environment, -Xms16M is
>> fine and that the assertion that a low -Xms value could result in
>> memory shortages at runtime or thread freezes is silly.
> 
> Providing -Xmx is set appropiately and the OS is able to respond
> promptly when the java process requests more memory then such a
> statement seems silly. Gc logging is the way to confirm what is
> happening.

And a thread dump wouldn't hurt either.

Mark

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

Re: [logging processes] Too many or Not too many?

[Mark Thomas]

On 18/02/2012 21:57, Pae Choi wrote:
> Tomcat v7.0.25
> CentOS 5.7 32bit
> 
> Running the tomcat without any webapp deployed, the system shows about
> 38 processes(i think)
> related to logging. Why that many and what are they logging about?
> 
> I see some of logging under the "$CATALINA_HOME/logs" folder and they
> seemed to be reasonably
> needed. But what others related to that many logging processes?

1. Don't hijack threads.

2. Be patient.

Mark

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

Re: Keystore password not masked in server.xml file

[Mark Thomas]

On 19/02/2012 09:25, Pae Choi wrote:
> On 02/14/2012 09:32 AM, Caldarale, Charles R wrote:
>>> From: Luca Marchesano [mailto:luca.marches...@ericsson.com]
>>> Subject: Keystore password not masked in server.xml file
>>> Is there a way to specify the keystore's password in encrypted way?
>> Think about it: where are you going to put the encryption key so
>> Tomcat can get at it to decode the encrypted password?  Eventually,
>> something must be in plain text, accessible to Tomcat.  Secure your
>> Tomcat configuration files so you don't have to worry about random
>> users looking at them.
>>
>>   - Chuck
>>
> 
> The OP's inquiry was quite reasonable as well as valid in a security
> aspect.

No it wasn't. It was illogical. Chris has already pointed to the FAQ
entry that discusses this in more detail. I don't propose to repeat
those arguments here but I will say the proposal below is nonsense.

Mark

> The 'password' for
> the key store falls in the same category. I remember there were more
> than a few times the same and
> similar subject addressed, but i guess it's still as it was.
> 
> To give an idea in terms of where to place and how to access,
> 
> 1) The clear-text or enciphered-form password in the code.
> 2) The clear-text password in the connector in the server.xml can be
> replaced with the API method
>name that can provide the password.
> 
> This simple mechanism can be either or both by Tomcat as default and/or
> custom-class that implements
> the defined API.
> 
> Within the implementation, how the API method provided the password can
> be left to the implementation
> provider. In that way, each Tomcat will have unique as well as more
> secure depends how well implemented
> the password provisioning class implemented which can be left to the
> implementation provider.
> 
> Anyhow, this is a basic idea where the password can be placed and how it
> can be accessed. And it can be
> easily implemented with reasonably short amount of time and effort.
> 
> To go further more for multiple certificates for multiple vHosts such as
> SNI+OpenSSL(or alternatives),
> it will be a bit more challenging, but not so hard about it.
> 
> 
> Pae
> 
> 
> 
> 


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

Re: Keystore password not masked in server.xml file

[Mark Thomas]

On 19/02/2012 12:17, Pae Choi wrote:
> On 02/19/2012 06:03 AM, Mark Thomas wrote:
>> On 19/02/2012 09:25, Pae Choi wrote:
>>> On 02/14/2012 09:32 AM, Caldarale, Charles R wrote:
>>>>> From: Luca Marchesano [mailto:luca.marches...@ericsson.com]
>>>>> Subject: Keystore password not masked in server.xml file
>>>>> Is there a way to specify the keystore's password in encrypted way?
>>>> Think about it: where are you going to put the encryption key so
>>>> Tomcat can get at it to decode the encrypted password?  Eventually,
>>>> something must be in plain text, accessible to Tomcat.  Secure your
>>>> Tomcat configuration files so you don't have to worry about random
>>>> users looking at them.
>>>>
>>>>- Chuck
>>>>
>>> The OP's inquiry was quite reasonable as well as valid in a security
>>> aspect.
>> No it wasn't. It was illogical. Chris has already pointed to the FAQ
>> entry that discusses this in more detail. I don't propose to repeat
>> those arguments here but I will say the proposal below is nonsense.
>>
>> Mark
>>
> 
> Which part of OP's comment illogical? is concerning the clear-text
> password illogical?

Yes.

> Where is the part in the FAQ that describe *in more detail* part? I'll
> be interesting to
> read about it.

Try reading the FAQ link Chris already pointed you to then.

> Nonsense? Is logical and rational simply saying nonsense without any
> logical explanation?

As I previously stated, the FAQ article provides all the explanation
required and I don't intend wasting my time copying and pasting it into
an email message.

> You could point out which part specifically you do not understand.
> Perhaps, security topic is too much for you to digest?

ROTFLMAO. I'll leave folks to check the archives to determine our
relative credibility on that one. I'm confident I know what the result
will be.

> When you do not understand, you simply just don't get it.

Hopefully, but I suspect not, you'll come to the conclusion that it is
in fact the other way around and that it is you that doesn't get it.

> Pae
> 
> P.S.: Also, why I am seeing your post without my original posting? How
> funny!

Yes, it is hilarious that you appear to be unable to configure your
browser to show message threads correctly.

I don't intend feeding this troll any further by replying to whatever
reply this e-mail may generate but I do offer the following food for
thought:

When on an Apache mailing list and someone with an @apache.org address
writes something you think is nonsense, there is a fairly good chance
that they do in fact know what they are talking about. You may want to
do a little more research before you start questioning their
intelligence. I'm not saying that they won't make mistakes (and when
they do, they'll be more than happy to own up to them), but it is
advisable to be very sure of your ground before you start typing unless
- of course - you are happy making yourself look like a complete idiot.

Mark


>>> The 'password' for
>>> the key store falls in the same category. I remember there were more
>>> than a few times the same and
>>> similar subject addressed, but i guess it's still as it was.
>>>
>>> To give an idea in terms of where to place and how to access,
>>>
>>> 1) The clear-text or enciphered-form password in the code.
>>> 2) The clear-text password in the connector in the server.xml can be
>>> replaced with the API method
>>> name that can provide the password.
>>>
>>> This simple mechanism can be either or both by Tomcat as default and/or
>>> custom-class that implements
>>> the defined API.
>>>
>>> Within the implementation, how the API method provided the password can
>>> be left to the implementation
>>> provider. In that way, each Tomcat will have unique as well as more
>>> secure depends how well implemented
>>> the password provisioning class implemented which can be left to the
>>> implementation provider.
>>>
>>> Anyhow, this is a basic idea where the password can be placed and how it
>>> can be accessed. And it can be
>>> easily implemented with reasonably short amount of time and effort.
>>>
>>> To go further more for multiple certificates for multiple vHosts such as
>>> SNI+OpenSSL(or alternatives),
>>> it will be a bit more challenging, but not so hard about it.
>>>
>>>
>>> Pae
>>>
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

[ANN] Apache Tomcat 7.0.26 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.26

This release is primarily a bug fix release and includes numerous
bug fixes compared to version 7.0.25. The notable bug fixes include:
* Improved @HandlesTypes processing which no longer loads
  all classes on web application start.
* Ensure that POST bodies are available for reply after FORM
  authentication when using the AJP connectors
* Corrected a regression that broke annotation scanning for many use
  cases including web applications packaged as WARs and many embedded
  scenarios.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note that this version has 4 zip binaries: a generic one and three
bundled with Tomcat native binaries for Windows operating systems
running on different CPU architectures.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team

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

Re: parallel deployment: multiple applications responding

[Mark Thomas]

On 23/02/2012 06:51, Aristedes Maniatis wrote:
> We've been using parallel deployment for some time now with tomcat
> 7.0.25. For the most part the parallel deployment is a really nice idea,
> particularly because we don't have sessions serialised and clustered
> across all running instances.
> 
> However, we've had mysterious problems for some time now where fixes
> we've applied to the application don't seem to work. We added some
> logging and have confirmed that some requests are still being served by
> the OLD instances of the application which are still deployed in the
> tomcat container but have an older version and therefore should not be
> responding. We might have two apps like this (using a format of YYMMDD
> and a two digit sequence):
> 
> enrol##12022203.war
> enrol##12021503.war
> 
> We would expect that requests would be served from only the newer
> application, but we find that requests continue to be served from the
> old, even though all the sessions to the old application are long dead.
> 
> Just to confirm things we have another application which does not use
> sessions at all. It also has the same problem: requests are being served
> by the wrong application.
> 
> 
> In Tomcat Manager, the old application is still marked as running, but
> we thought this is just how it appears in the UI. Clearly there is
> something not right here.
> 
> 
> 1. Is this a known issue?

We'd need to understand the root cause to answer that. The short version
is that requests will only be routed to the old version if a request
includes a session ID that references it. I'd suggest adding the session
cookie to your access log.

> 2. Is there some way to get the old application to fully undeploy as
> soon as it has no live sessions?

No. It is on the to do list.

> We have been thinking about writing an
> external application to poll using JMX and do this, but that's quite a
> bit of work. It would be nicer if this happened inside tomcat itself.

Agreed. Patches welcome.

> 3. Is there some resource we might be hanging onto which is preventing
> the old application from properly stopping?

Maybe. But that would be a separate issue.

> 4. Should the tomcat manager show the older apps as still running or
> should they be shown as stopped?

running.

Mark

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

Re: distributable mode does not work with Servlet 3.0

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/02/2012 14:33, Pid wrote:
> On 27/02/2012 13:16, Christopher Schultz wrote:
>> Lucas,
>> 
>> On 2/27/12 5:36 AM, Lucas Pouzac wrote:
>>> a library (prettyfaces) uses a web-tag fragment without 
>>> 
>> 
>>> With metadata-complete="true", It works correctly.
>> 
>> Interesting.
> 
> +1  That seems surprising.  I don't see why the fragment would
> impact this.

Not at all surprising. Servlet 3.0, section 8.2.3, 5.g.ix

The web.xml resulting from the merge is considered 
only if all its web fragments are marked as  as well.


>> We should probably issue a warning if a web fragment disagrees
>> with a definite value for the "distributable" flag in the 
>> webapp's web.xml.
> 
> How would it do that?  There's no such tag as
> .

It could be done easily on the merge but I'd be strongly against it.
There are lots of rules for merging web fragments and I don't think we
should be logging very decision that gets made.

> Shouldn't the web.xml value override the fragment value(s), in this
> case?

No. See above.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPS5cjAAoJEBDAHFovYFnn5I8P/3iKBbpuhIbVDh9XBjQakRML
G9cN5aaL5sZbLZ5kbGhtulIY5MeKrt/dbEJMwBR6hEdwyUD1AbxTUzu2CuQMNnZT
zkQokXJmUvSqV7/L1MBY+FRGKJviFbcgCQEQqloywrkPeMolLsm3M/ZUMu04jm+z
AkEH6RMPUeJqOd5m2J+0olEU51qYXRYCm5clK1Q4wM6idIfqK1/kjCEcC1CHLFCv
+Ao6XZmj71Ld1id87mO0ciuxniARJ9wKjVegby4DUK/rIhTWmDsdeWC1gSdpHSbn
bBhoc27CPIv+N7apbe3ILsD1fw3Gb3O6Q2LbQxqBMRGJZCxEwMdHZpmXDu9jyIM2
9wHvV2KjyvGiivi1bk8eqwsDnc06umBUoGdEAb8KwTY7AOqVgnyOQnkeB6IWEcwx
3SPBqHd9PMB2wnyquIb0EKLOkNCfmvbuUkYAfz9wROzfzUt/fzDNvGMjVpSEcAap
Zztf/E7aJmsjvNeseAjpf31EMEM+J0ftqoRG3ZRT5UyCy6NQmUzB72D/9mEAPirN
ayaSmahgt5yTv5eqGkNmr/AowFMNZkIekRc9xyNTGb3YwN0sNNVGnD/krQd/MbdF
yWCPP1IQlTxGa6kRXFewBvo8OzyJ0rVMquP6gtZ9JPWk9Q4gozhL/fHu4xBoY8d2
Q97nYUSY9Sl5oOwQK4BF
=NWDF
-END PGP SIGNATURE-

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

Re: Inconsistency in AprEndpoint.java and JIoEndpoint.java

[Mark Thomas]

On 28/02/2012 16:40, Ken Cheung wrote:
> I observed some code clones in Tomcat and found inconsistent code.
> Could anyone explain why this is not a bug?

Yes.

Perhaps you'd like to explain your basis for assuming it is a bug.

Mark

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

Re: Create a tomcat 7 instance

[Mark Thomas]

On 28/02/2012 16:26, André Moraes wrote:
> Hello everyone, can someone help me to create an instance of tomcat 7 as a
> service?
> How do I set up several instances of tomcat 7 without the installer?

service.bat

Mark

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