Re: Tomcat 7 Maven plugin: deploy fails with tomcatManager status code:401, ReasonPhrase:Unauthorized

2012-04-13 Thread Olivier Lamy
Hi,
Can you try with: mvn tomcat7:deploy -Dtomcat.username=Administrator
-Dtomcat.password=a

See Mojo documentation:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html

2012/4/13 Matt Munz matt.m.m...@gmail.com:
 Olivier,

  When I try to deploy from Maven, the following message appears in the access 
 log. [1]  There are no other messages in any of the other logs for this event.

 [1] 127.0.0.1 - - [12/Apr/2012:21:15:59 -0700] PUT 
 /manager/html/deploy?path=%2F HTTP/1.1 401 2550

  Matt

 On Apr 12, 2012, at 6:46 PM, Matt Munz wrote:

 Olivier,

   Thanks for getting to this.

 Do you have more logs/details from your tomcat instance ?
 Especially: $CATALINA_HOME/logs/localhost_access_log.-MM-dd.txt
 and entries corresponding to the deployment

   I will collect these and send them in a subsequent email.

 Are you passing tru a http server which is proxying/redirecting to the
 Tomcat instance ?

   Nope.  This is on an OS X machine.  All I did was install Tomcat 7 in a 
 local directory, modify tomcat-users.xml as I described below, and start 
 Tomcat.

 What kind of deployment are you doing ? one with contextFile parameter ?

   No, I'm just using the parameters I mentioned previously. [1]

 [1] mvn tomcat7:deploy -Dusername=Administrator -Dpassword=a

   Matt

 On Apr 12, 2012, at 3:54 PM, Olivier Lamy wrote:

 Hello,
 Currently, I cannot reproduce.
 Do you have more logs/details from your tomcat instance ?
 Especially: $CATALINA_HOME/logs/localhost_access_log.-MM-dd.txt
 and entries corresponding to the deployment
 Are you passing tru a http server which is proxying/redirecting to the
 Tomcat instance ?
 What kind of deployment are you doing ? one with contextFile parameter ?


 2012/4/6 Matt Munz matt.m.m...@gmail.com:
 Olivier,

  OK.  Thanks.  So with the 2.0-SNAPSHOT version I am getting the same 
 error (HTTP 401). [1]  Interestingly, the plugin output makes it look like 
 the WAR file was uploaded but when I visit the Manager, I can see that it 
 is not deployed.

  Do you have any thoughts about what I can do to debug this further?  I'd 
 really like to get this working.

 [1]
 [INFO] Deploying war to http://localhost:8080/
 Uploading: http://localhost:8080/manager/html/deploy?path=%2F
 Uploaded: http://localhost:8080/manager/html/deploy?path=%2F (9555 KB at 
 33760.1 KB/sec)
 [INFO] tomcatManager status code:401, ReasonPhrase:Unauthorized

  Matt


 On Apr 4, 2012, at 12:23 AM, Olivier Lamy wrote:

 Hello,
 Have a look here:
 http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html

 2012/4/4 Matt Munz matt.m.m...@gmail.com:
 Olivier,

  I made that change to settings.xml and now I'm getting a different 
 error. [1]  How can I find out where this plugin is stored?  Perhaps 
 there is a problem with the repository or my repository configuration.

 [1]
 [WARNING] The POM for 
 org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT is 
 missing, no dependency information available
 [WARNING] Failed to retrieve plugin descriptor for 
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT: Plugin 
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT or one of its 
 dependencies could not be resolved: Failed to read artifact descriptor 
 for org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT
 ...
 [WARNING] The POM for 
 org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT is 
 missing, no dependency information available
 ...
 [ERROR] Plugin org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT 
 or one of its dependencies could not be resolved: Failed to read 
 artifact descriptor for 
 org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT: Could not 
 find artifact 
 org.apache.tomcat.maven:tomcat7-maven-plugin:pom:2.0-SNAPSHOT - [Help 1]

  Matt Munz

 On Apr 2, 2012, at 11:48 PM, Olivier Lamy wrote:

 Hello,
 With version from codehaus manager url for tomcat7 is not correct.
 (see 
 http://mojo.codehaus.org/tomcat-maven-plugin/examples/deployment-tomcat7.html)

 Regarding the plugin prefix trouble, you have two solutions to use the
 correct version:

 * use the full cli: mvn
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:deploy
 * configure your settings.xml with the entry

  pluginGroups
    pluginGrouporg.apache.tomcat.maven/pluginGroup
  /pluginGroups


 HTH,
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 2012/4/3 Matt Munz matt.m.m...@gmail.com:
 Olivier,

  After switching to 2.0-SNAPSHOT, I am still getting errors :(  First 
 I got an error saying that the tomcat7 prefix was not found. [1]  Then 
 I tried mvn  tomcat:deploy -Dusername=Administrator -Dpassword=a and 
 I got a 403 response from the manager.

 [1]
 [ERROR] No plugin found for prefix 'tomcat7' in the current project 
 and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] 
 available from the repositories [local 
 

Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal

2012-04-13 Thread Leigh Anderson
Hi Olivier,

It's actually the act of declaring a context.xml with a Loader element
that causes the application to fail. A new instance of WebAppLoader is
created, overriding the one carefully created by the plugin, without the
benefit of a properly configured class path. I've included a small patch
below which demonstrates my intent.

I'd added 
classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomcat
InstrumentableClassLoader/classLoaderClass to the plugin configuration,
which was then picked up correctly and used by the WebAppLoader.

Thanks,
Leigh

Index: 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java
===
--- 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision 1)
+++ 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision )
@@ -363,6 +357,15 @@
  */
 private ClassRealm tomcatRealm;
 
+/**
+ * Class loader class to set.
+ *
+ * @parameter
+ */
+protected String classLoaderClass;
+
 // 
--
 // Mojo Implementation
 // 
--
@@ -460,14 +462,19 @@
 {
 context.setParentClassLoader( getTomcatClassLoader() );
 }
+final WebappLoader loader = createWebappLoader();
 
-context.setLoader( createWebappLoader() );
+context.setLoader( loader );
 File contextFile = getContextFile();
 if ( contextFile != null )
 {
 context.setConfigFile( getContextFile().toURI().toURL() );
 }
+if (classLoaderClass != null) {
+loader.setLoaderClass(classLoaderClass);
+}
 
+
 return context;
 
 }



On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:

The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the plugin ?

-- 
Olivier

[1] 
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/ru
n-mojo.html#contextFile

2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 That's solved the problem, thanks. Unfortunately, declaring a custom
class
 loader in a context.xml causes Tomcat to use that one, instead of the
one
 set up with the correct class path by the plugin. I'll keep looking to
see
 if I can find a way around this.

 Thanks for your prompt help with this.
 Leigh

 On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:

Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
 Hello Leigh,
 Thanks for creating issue.
 Until now I tried to reproduce the issue but I failed.
 I wonder if you could attach a build log using -e mvn flag.

 2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
 get the issue created -- should have some time next week to put
together a
 sample project.


 Thanks,
 Leigh

 On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:

Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
 Hi All,

 I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
 that with the configuration below it fails with the following
error:


[INFO]


--
--
[ERROR] Failed to execute goal
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
 on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
 -e switch.
[ERROR] Re-run Maven using the -X switch to enable full
debug
logging.

 I have also tried
* 'mvn tomcat:run-war', which seems to get past this point,
but
then the
 application will not start because the 'additionalClasspathDir'
property
 is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
 Spring instrumenting class loader required to use AspectJ LTW,
specified
 in
 context.xml. I have confirmed that I get the same 'no such
archiver'
error
 if I remove the
 context.xml, so I don't believe this to be the cause.

 Is there something I've missed in the configuration?

 Cheers,
 Leigh




plugin

Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal

2012-04-13 Thread Olivier Lamy
Hi,

2012/4/13 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 It's actually the act of declaring a context.xml with a Loader element
 that causes the application to fail. A new instance of WebAppLoader is
 created, overriding the one carefully created by the plugin, without the
 benefit of a properly configured class path. I've included a small patch
 below which demonstrates my intent.

Oh sure good catch.


 I'd added
 classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomcat
 InstrumentableClassLoader/classLoaderClass to the plugin configuration,
 which was then picked up correctly and used by the WebAppLoader.

Could you attach the patch to an issue ?


 Thanks,
 Leigh

 Index:
 tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
 un/AbstractRunMojo.java
 ===
 ---
 tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
 un/AbstractRunMojo.java (revision 1)
 +++
 tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
 un/AbstractRunMojo.java (revision )
 @@ -363,6 +357,15 @@
      */
     private ClassRealm tomcatRealm;

 +    /**
 +     * Class loader class to set.
 +     *
 +     * @parameter
 +     */
 +    protected String classLoaderClass;
 +
     //
 --
     // Mojo Implementation
     //
 --
 @@ -460,14 +462,19 @@
         {
             context.setParentClassLoader( getTomcatClassLoader() );
         }
 +        final WebappLoader loader = createWebappLoader();

 -        context.setLoader( createWebappLoader() );
 +        context.setLoader( loader );
         File contextFile = getContextFile();
         if ( contextFile != null )
         {
             context.setConfigFile( getContextFile().toURI().toURL() );
         }
 +        if (classLoaderClass != null) {
 +            loader.setLoaderClass(classLoaderClass);
 +        }

 +
         return context;

     }



 On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:

The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the plugin ?

--
Olivier

[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/ru
n-mojo.html#contextFile

2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 That's solved the problem, thanks. Unfortunately, declaring a custom
class
 loader in a context.xml causes Tomcat to use that one, instead of the
one
 set up with the correct class path by the plugin. I'll keep looking to
see
 if I can find a way around this.

 Thanks for your prompt help with this.
 Leigh

 On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:

Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
 Hello Leigh,
 Thanks for creating issue.
 Until now I tried to reproduce the issue but I failed.
 I wonder if you could attach a build log using -e mvn flag.

 2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
 get the issue created -- should have some time next week to put
together a
 sample project.


 Thanks,
 Leigh

 On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:

Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
 Hi All,

 I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
 that with the configuration below it fails with the following
error:


        [INFO]


--
--
        [ERROR] Failed to execute goal
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
 on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
        [ERROR]
        [ERROR] To see the full stack trace of the errors, re-run
Maven
with the
 -e switch.
        [ERROR] Re-run Maven using the -X switch to enable full
debug
logging.

 I have also tried
        * 'mvn tomcat:run-war', which seems to get past this point,
but
then the
 application will not start because the 'additionalClasspathDir'
property
 is not supported by the 'run-war' goal.
        * removing 'useSeparateTomcatClassLoader' which then doesn't
load the
 Spring instrumenting class loader required to use AspectJ LTW,
specified
 in
 context.xml. I have confirmed that I get the same 'no such
archiver'
error
 if I remove the
 context.xml, so I don't believe this to be the 

determining cause of MaxThreads exhausted

2012-04-13 Thread Miguel González Castaños

Dear all,

  A server that I manage has a Struts webapp with a Tomcat 5.5.x 
standalone server. No JMX or whatsoever has been configured.


  The app sends massive emails to users with some info that requires 
users to log on the webapp and fill in some forms. It seems (without any 
logs or metrics) that people tend to fill the forms right away after 
they got the emails and together with the mailing process (that requires 
DB use to get email addresses) is exhausting the maxthreads connections 
(300 as of yesterday which I have increased to 400).


  I assume it's not going to be easy to determine what is the cause of 
the issue but which tools can I use?


  I guess I need to log in some way how the server is behaving. Maybe 
enabling JMX or Javamelody? Any way of getting where the webapp is 
hanged or where in the code of the webapp is hanging?


  And which tool can help me to simulate the load of so many people 
connecting to the webapp remotely?


  Regards,

  Miguel

This message and any attachments are intended for the use of the addressee or 
addressees only. The unauthorised disclosure, use, dissemination or copying 
(either in whole or in part) of its content is not permitted. If you received 
this message in error, please notify the sender and delete it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.


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



Re: determining cause of MaxThreads exhausted

2012-04-13 Thread Pid *
On 13 Apr 2012, at 09:09, Miguel González Castaños
miguel_3_gonza...@yahoo.es wrote:

 Dear all,

  A server that I manage has a Struts webapp with a Tomcat 5.5.x standalone 
 server. No JMX or whatsoever has been configured.

  The app sends massive emails to users with some info that requires users to 
 log on the webapp and fill in some forms. It seems (without any logs or 
 metrics) that people tend to fill the forms right away after they got the 
 emails and together with the mailing process (that requires DB use to get 
 email addresses) is exhausting the maxthreads connections (300 as of 
 yesterday which I have increased to 400).

How many emails does it send?

  I assume it's not going to be easy to determine what is the cause of the 
 issue but which tools can I use?

It might just be simple maths. If you send more than 400 emails and
most of those people immediately respond, what would you expect to
happen?


  I guess I need to log in some way how the server is behaving. Maybe enabling 
 JMX or Javamelody? Any way of getting where the webapp is hanged or where in 
 the code of the webapp is hanging?

Access log?
Enable JMX, use VisualVM/JConsole.


  And which tool can help me to simulate the load of so many people connecting 
 to the webapp remotely?

JMeter.


p



  Regards,

  Miguel

 This message and any attachments are intended for the use of the addressee or 
 addressees only. The unauthorised disclosure, use, dissemination or copying 
 (either in whole or in part) of its content is not permitted. If you received 
 this message in error, please notify the sender and delete it from your 
 system. Emails can be altered and their integrity cannot be guaranteed by the 
 sender.

 Please consider the environment before printing this email.


 -
 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: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal

2012-04-13 Thread Leigh Anderson



 I'd added
 
classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomc
at
 InstrumentableClassLoader/classLoaderClass to the plugin
configuration,
 which was then picked up correctly and used by the WebAppLoader.

Could you attach the patch to an issue ?

MTOMCAT-140 created.



 Thanks,
 Leigh

 Index:
 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
 un/AbstractRunMojo.java
 ===
 ---
 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
 un/AbstractRunMojo.java (revision 1)
 +++
 
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
 un/AbstractRunMojo.java (revision )
 @@ -363,6 +357,15 @@
  */
 private ClassRealm tomcatRealm;

 +/**
 + * Class loader class to set.
 + *
 + * @parameter
 + */
 +protected String classLoaderClass;
 +
 //
 --
 // Mojo Implementation
 //
 --
 @@ -460,14 +462,19 @@
 {
 context.setParentClassLoader( getTomcatClassLoader() );
 }
 +final WebappLoader loader = createWebappLoader();

 -context.setLoader( createWebappLoader() );
 +context.setLoader( loader );
 File contextFile = getContextFile();
 if ( contextFile != null )
 {
 context.setConfigFile( getContextFile().toURI().toURL() );
 }
 +if (classLoaderClass != null) {
 +loader.setLoaderClass(classLoaderClass);
 +}

 +
 return context;

 }



 On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:

The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the
plugin ?

--
Olivier

[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/
ru
n-mojo.html#contextFile

2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 That's solved the problem, thanks. Unfortunately, declaring a custom
class
 loader in a context.xml causes Tomcat to use that one, instead of the
one
 set up with the correct class path by the plugin. I'll keep looking to
see
 if I can find a way around this.

 Thanks for your prompt help with this.
 Leigh

 On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:

Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
 Hello Leigh,
 Thanks for creating issue.
 Until now I tried to reproduce the issue but I failed.
 I wonder if you could attach a build log using -e mvn flag.

 2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
 Hi Olivier,

 I'm not able to run this with tomcat6 as it's a Servlet 3.0
project.
I'll
 get the issue created -- should have some time next week to put
together a
 sample project.


 Thanks,
 Leigh

 On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:

Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
 Hi All,

 I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
 that with the configuration below it fails with the following
error:


[INFO]

--
--
--
--
[ERROR] Failed to execute goal
 org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
 on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
 -e switch.
[ERROR] Re-run Maven using the -X switch to enable full
debug
logging.

 I have also tried
* 'mvn tomcat:run-war', which seems to get past this
point,
but
then the
 application will not start because the 'additionalClasspathDir'
property
 is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then
doesn't
load the
 Spring instrumenting class loader required to use AspectJ LTW,
specified
 in
 context.xml. I have confirmed that I get the same 'no such
archiver'
error
 if I remove the
 context.xml, so I don't believe this to be the cause.

 Is there something I've missed in the configuration?

 Cheers,
 Leigh




plugin
groupIdorg.apache.tomcat.maven/groupId

artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties


Re: determining cause of MaxThreads exhausted

2012-04-13 Thread Miguel González Castaños

On 13/04/2012 10:14, Pid * wrote:

On 13 Apr 2012, at 09:09, Miguel González Castaños
miguel_3_gonza...@yahoo.es  wrote:


Dear all,

  A server that I manage has a Struts webapp with a Tomcat 5.5.x standalone 
server. No JMX or whatsoever has been configured.

  The app sends massive emails to users with some info that requires users to 
log on the webapp and fill in some forms. It seems (without any logs or 
metrics) that people tend to fill the forms right away after they got the 
emails and together with the mailing process (that requires DB use to get email 
addresses) is exhausting the maxthreads connections (300 as of yesterday which 
I have increased to 400).

How many emails does it send?

Around 1000 a minute



  I assume it's not going to be easy to determine what is the cause of the 
issue but which tools can I use?

It might just be simple maths. If you send more than 400 emails and
most of those people immediately respond, what would you expect to
happen?



  I guess I need to log in some way how the server is behaving. Maybe enabling 
JMX or Javamelody? Any way of getting where the webapp is hanged or where in 
the code of the webapp is hanging?

Access log?
Enable JMX, use VisualVM/JConsole.
Any way to use access log to get a view of how many visitors (not 
connections) we are getting?






  And which tool can help me to simulate the load of so many people connecting 
to the webapp remotely?

JMeter.
Any howto or article that explains of how to use JMeter in an 
environment like this?


Miguel

This message and any attachments are intended for the use of the addressee or 
addressees only. The unauthorised disclosure, use, dissemination or copying 
(either in whole or in part) of its content is not permitted. If you received 
this message in error, please notify the sender and delete it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.


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



Multipart over ajp btwn apache-tomcat fails sometimes...

2012-04-13 Thread Svante Kumlien
Hi all,

My stuff:
Windows Server 2008 R2 64 bit
Apache 2.2.22 with mod_proxy_ajp
Tomcat 7.0.25 (On same server as Apache)

I have an Apache acting as reverse proxy for a Tomcat over ajp.
Apache conf for the proxyPass:
Location /tomcatSite
ProxyPass ajp://127.0.0.1:8009/tomcatSite
ProxyPassReverse ajp://127.0.0.1:8009/tomcatSite
/Location

and the tomcat-config is really basic with nothing added to the default
config.

The webapp listening on /tomcatSite is a servlet-2.5 app and it works
nicely for all types of request except when it comes to multi-part. We have
a java-client uploading .zip-files every night to this webapp and sometimes
it works and sometimes it fails. When testing we trigger the file upload
manually using the same zip file every time with the same result: sometimes
it works, and sometimes it fails.

What happens when it works:
Client sends multipart http-request to Apache.
Apache proxy to Tomcat over AJP
Servlet is called on doPost
Servlet uses apache-commons-fileupload 1.2 to parse the request
Servlet does something with the file
Servlet returns (200 OK)

What happens when it doesn't work:
Client sends http-requst
Apache proxy request
Servlet is called on doPost
Servlet uses apache-commons-fileupload
Commons-fileupload throws an Exception with message Stream closed
(Gaahhh, the stack trace is swallowed, I only have the message string! The
exception is thrown from  FileUploadBase.parseRequest :-( )
Servlet sends an email to admin
Servlet returns 200 OK

The behaviour seem random but I would say that it fails 80% using the same
file, same server, no restart.

I attach two pcap-files with a ok-case and a fail-case. The difference I
can see is that in the fail-case tomcat starts to send the response before
the first Body chunk is sent by Apache. In the ok-case the first Body-chunk
is sent by Apache the same millisecond as the first Request packet but in
the failing case the first Body chunk is sent a couple of millis after the
first packet somehow allowing Tomcat/my servlet to fail before the complete
request is received.

If we switch the proxyPass to use http everything works 100% of the time
(which makes me think I have a misconfig AJP connector somewhere...).

Any ideas/pointers are more than welcome!

br
Svante

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

RE: StandardHostValve kills custom error message

2012-04-13 Thread Osipov, Michael
Konstantin Kolinko wrote:
 
 The message is not diplayed because in line 282 to 286 the message
 is killed by: 
 else {
            // A custom error-page has not been defined for the
 exception 
            // that was thrown during request processing. Check if an
            // error-page for error code 500 was specified and if so,
            // send that page back as the response.
          
 response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); 
            // The response is an error
            response.setError();
 
            status(request, response);
        }
 
 It seems like this valve does not care if it handles an uncaught
 exception or a deliberate exception. 
 Can this be fixed without patching the valve?
 
 I guess not. I would file a ticket about that: A mere
 response#isError call would suffice to wrap that behavior and pass
 the response as is.  
 
 
 
 My understanding is that it is responsibility of the Container to
 provide the value for the request attribute
 javax.servlet.error.exception

There is simple fix. A examined other server-side component how they set that 
attribute and adapted my code.
All you need to do is described in my new ticket: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53071

With best regards,
Michael Osipov

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



Re: Tomcat 7 Maven plugin: deploy fails with tomcatManager status code:401, ReasonPhrase:Unauthorized

2012-04-13 Thread Konstantin Kolinko
2012/4/13 Matt Munz matt.m.m...@gmail.com:
 Olivier,

  When I try to deploy from Maven, the following message appears in the access 
 log. [1]  There are no other messages in any of the other logs for this event.

 [1] 127.0.0.1 - - [12/Apr/2012:21:15:59 -0700] PUT 
 /manager/html/deploy?path=%2F HTTP/1.1 401 2550

manager/html/deploy?

That is what is used when you use HTML GUI of the manager app.

Automated tools use Text interface, not HTML one.

It has different address (and requires different user role).

Best regards,
Konstantin Kolinko

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



Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m

2012-04-13 Thread markt
Peter peterdni...@yahoo.com wrote:

Thanks for the response Mark - it is consistent with both observations
that i noted in the original email (heap post startup was near 0, and
disabling scanning resolves). I looked in the changelog in 26/27 and
did not see anything in there that fits this?  If your hypothesis is
correct , I suspect quite a few people will be in for a shock when they
deploy 7.0.27 or later into a production env where memory footprints
are much more managed then say in eclipse on your desktop ;)

The issue might not be with the spec, but the tomcat implementation
where by everything is getting loaded into ram during scanning. In
7.0.25 - I could start a typical Spring application in 32mb. 7.0.27
requires 512mb? 


- Peter




 From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 11, 2012 6:50 AM
Subject: Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m
 


Pid p...@pidster.com wrote:

On 11/04/2012 03:47, Peter wrote:
 hey Christopher,
 
 the app I used that uncovered the issue is one I use exclusively to
validate tomcat releases;) it is a hello world style app using
spring/servlet3.0. it has simple spring aop point cutting via jamon ,
simple spring jms (active mq) simple spring jaxrs, simple spring
jaxws,
simple spring mvc, simple spring security,... (spring 3.0.7)
 
 bunch of very simple examples that end up pulling in many jars.

Can you post it to github or somewhere public?


p


 I will grab a dump tomorrow,  thanks for response,
 peter

I know exactly where this memory is going. During the scanning process
Tomcat has to scan every single class in the application and its
libraries and every class and interface in that class's hierarchy for
annotations (we don't have a choice in this - the spec requires it).
This can lead to the same class being scanned many times during startup
and that is slow. Tomcat now caches the result of scanning a class
which means each class only has to be scanned once. However, this does
mean that all the results are in memory until the scan is complete. If
you have a lot of libraries, that could require a lot of memory. If you
know a JAR doesn't need scanning, add it to the jarsToSkip property. If
it is a popular jar then create an enhancement request and we'll add it
to the default list. The other option is to set metadata complete in
the web.xml

I haven't reviewed the scanning caching code but there may be some
opportunities to reduce the memory footprint of the cache.

Mark


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

The specification requires that every class and its hierarchy is scanned for 
annotations when the web app start. It was the Spring folks complaining about 
the slow start time when we didn't cache anything during the scan process.

As I have said before:
- If you don't need to scan jars, add them to the skip list. If they are common 
jars tell us what they are and we'll add them.
- If you do need to scan them the memory usage is the price you pay for fast 
startup. I have not reviewed the cache code to see if it could be more 
efficient.

Mark

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



Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m

2012-04-13 Thread Konstantin Kolinko
2012/4/13  ma...@apache.org:

 The specification requires that every class and its hierarchy is scanned for 
 annotations when the web app start. It was the Spring folks complaining about 
 the slow start time when we didn't cache anything during the scan process.

 As I have said before:
 - If you don't need to scan jars, add them to the skip list. If they are 
 common jars tell us what they are and we'll add them.

or add metadata-complete=true to the root element of your web.xml

 - If you do need to scan them the memory usage is the price you pay for fast 
 startup. I have not reviewed the cache code to see if it could be more 
 efficient.

Everybody else can help here. It is opensource.


BTW, here are patterns that I use in some of my configurations
(configured for Spring 2.5, 3.0 applications).

I have not run all my apps on 7.0.27 yet, but some run on 7.0.27 already.

Line ends added for readability.

I have not reviewed Spring 3.1 yet.

aopalliance-*.jar,
cglib-*.jar,
spring-security-acl-2.*.jar,
spring-security-catalina-2.*.jar,
spring-security-core-2.*.jar,
spring-security-core-tiger-2.*.jar,
spring-security-acl-3.*.jar,
spring-security-aspects-3.*.jar,
spring-security-cas-client-3.*.jar,
spring-security-config-3.*.jar,
spring-security-core-3.*.jar,
spring-security-ldap-3.*.jar,
spring-security-openid-3.*.jar,
spring-security-web-3.*.jar,
spring.jar,
spring-2.*.jar,
spring-aop*.jar,
spring-beans*.jar,
spring-context*.jar,
spring-core*.jar,
spring-jdbc*.jar,
spring-jms*.jar,
spring-orm*.jar,
spring-test*.jar,
spring-tx*.jar,
spring-web.jar,
spring-web-2.*.jar,
spring-webmvc-portlet*.jar,
spring-webmvc-struts*.jar,
org.springframework.aop-3.*.jar,
org.springframework.asm-3.*.jar,
org.springframework.aspects-3.*.jar,
org.springframework.beans-3.*.jar,
org.springframework.context.support-3.*.jar,
org.springframework.context-3.*.jar,
org.springframework.core-3.*.jar,
org.springframework.expression-3.*.jar,
org.springframework.instrument.tomcat-3.*.jar,
org.springframework.instrument-3.*.jar,
org.springframework.jdbc-3.*.jar,
org.springframework.jms-3.*.jar,
org.springframework.orm-3.*.jar,
org.springframework.oxm-3.*.jar,
org.springframework.test-3.*.jar,
org.springframework.transaction-3.*.jar,
org.springframework.web.portlet-3.*.jar,
org.springframework.web.struts-3.*.jar,
org.springframework.web-3.*.jar,

Best regards,
Konstantin Kolinko

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



Re: determining cause of MaxThreads exhausted

2012-04-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Miguel,

On 4/13/12 4:27 AM, Miguel González Castaños wrote:
 The app sends massive emails to users with some info that requires 
 users to log on the webapp and fill in some forms. It seems
 (without any logs or metrics) that people tend to fill the forms
 right away after they got the emails and together with the mailing
 process (that requires DB use to get email addresses) is exhausting
 the maxthreads connections (300 as of yesterday which I have
 increased to 400).

Are you running out of request processors (Connector maxThreads) or
are you running out of database connections (Resource maxActive)?

 How many emails does it send?
 Around 1000 a minute

I'm not sure the email volume has anything to do with the resource
availability, other than an email may intise someone to go to your
site, which will (temporarily) use up a request processor thread and
(possibly) a database connection.

 Any way to use access log to get a view of how many visitors (not 
 connections) we are getting?

Yes: log the timestamp of each access, then use one of the many fine
web server analysis tools to get a picture (literally) of your volume.

 Any howto or article that explains of how to use JMeter in an 
 environment like this?

JMeter is used virtually the same way in all environments: only you
understand the nuances of your own software and can craft a load test
that is appropriate for your application.

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

iEYEARECAAYFAk+IjZsACgkQ9CaO5/Lv0PCtIQCgkZQncIn89KmLG5dvTyweJ90q
xtYAn1aeBsx+W97Kx0sqeIq489HFFKXF
=PKaP
-END PGP SIGNATURE-

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



Re: determining cause of MaxThreads exhausted

2012-04-13 Thread Miguel González Castaños



The app sends massive emails to users with some info that requires
users to log on the webapp and fill in some forms. It seems
(without any logs or metrics) that people tend to fill the forms
right away after they got the emails and together with the mailing
process (that requires DB use to get email addresses) is exhausting
the maxthreads connections (300 as of yesterday which I have
increased to 400).

Are you running out of request processors (Connector  maxThreads) or
are you running out of database connections (Resource  maxActive)?

MaxThreads

Yes: log the timestamp of each access, then use one of the many fine
web server analysis tools to get a picture (literally) of your volume.
I have an access log with timestamps, which tool do you recommend to get 
an analysis?


Regards,

Miguel

This message and any attachments are intended for the use of the addressee or 
addressees only. The unauthorised disclosure, use, dissemination or copying 
(either in whole or in part) of its content is not permitted. If you received 
this message in error, please notify the sender and delete it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.


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



Re: Multipart over ajp btwn apache-tomcat fails sometimes...

2012-04-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Svante,

On 4/13/12 5:16 AM, Svante Kumlien wrote:
 I have an Apache acting as reverse proxy for a Tomcat over ajp.

Standard stupid question: are you sure you need Apache httpd in the mix?

 (Gaahhh, the stack trace is swallowed, I only have the message
 string! The exception is thrown from  FileUploadBase.parseRequest
 :-( )

Is there any way to get the full stack trace? Can you re-deploy with
some modified code to get it?

 I attach two pcap-files with a ok-case and a fail-case.

The mailing list has stripped your attachments. Try to copy/paste text
into a re-post or post a link to your file(s) instead.

 The difference I can see is that in the fail-case tomcat starts to
 send the response before the first Body chunk is sent by Apache.

Can you sniff the traffic between httpd and Tomcat?

Do you have large headers or anything like that? The AJP message could
be rejected because the headers don't fit into a single AJP packet --
but that shouldn't trigger a failure in FileUploadBase.

Is there HTTPS in the mix anywhere? Client certs can make the headers
large.

 If we switch the proxyPass to use http everything works 100% of the
 time (which makes me think I have a misconfig AJP connector
 somewhere...).

Can you post the rest of your AJP configuration? For instance, what
does your Connector look like on the Tomcat side?

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

iEYEARECAAYFAk+Ij00ACgkQ9CaO5/Lv0PCULQCgoBmlLJJkuSpcXDUxbKLc0Ptl
eusAoLlVdrUsETpscxjlCaG04dO4/12e
=UpxR
-END PGP SIGNATURE-

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