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

2012-01-23 Thread 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: Tomcat 6.0.35-SocketException: Too many open files issue with

2012-01-23 Thread Purvis Robert (NHS CONNECTING FOR HEALTH)
Sorry to possibly state the obvious, but are there perhaps files that are not 
being closed?

This can often happen if code goes into a "catch", and a file is not closed. 
Best to have a "finally" block which checks if a file is open, and closes it.


Robert Purvis

-Original Message-
From: gnath [mailto:gautam_exquis...@yahoo.com]
Sent: 22 January 2012 08:01
To: users@tomcat.apache.org
Subject: Tomcat 6.0.35-SocketException: Too many open files issue with

Hello,

We have been seeing "SocketException: Too many open files" in production 
environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day and 
requires a restart of Tomcat. When this happened for the first time, we 
searched online and found people suggesting to increase the file descriptors 
size and we increased to 4096. But still the problem persists.  We have the 
Orion App Server also running on the same machine but usually during the day 
when we check the open file descriptor by command: ls -l /proc/PID/fd, its 
always less than 1000 combined  for both Orion and Tomcat.


Here is the exception we see pouring in the logs once it starts: This requires 
us to kill java process and restart tomcat. Our Tomcat configuration 
maxThreadCount is 500 with minSpareThreads=50 in server.xml


SEVERE: Socket accept failed
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
at 
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352)
at java.lang.Thread.run(Thread.java:662)

ulimit -a gives for the user where Tomcat is running.


open files  (-n) 4096


Please let me know what could be the issue here and how can i resolve this 'Too 
many open files' issue.

Thanks
-G



This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail



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



Re: New development, Re: More, Re: Problem bringing up SSL with a CA certificate

2012-01-23 Thread Ognjen Blagojevic

James,

On 19.1.2012 18:05, James Lampert wrote:

You must find keystore with earlier generated key pair (the one you
also used to generate CSR for CA), and import all three certificates
into that keystore.


At this point, I still don't have the keystore used to generate the CSR,
but I *do* now have the CSR itself. Does that help?


No, it doesn't.

Assuming you are NOT using APR connector, the whole procedure goes like 
this:


1. Generate key pair (public and private key) using keytool -genkeypair. 
Both keys are kept in the keystore.


2. Export public key into CSR, and send it to the CA.

3. Receive signed public key (certificate) from CA, along with any other 
necessary certificates forming keychain.


4. Import all received certificates to the keystore you used in step 1.

If you lost your keystore, that means that you lost private key. You 
need to start from the beginning. Generate new keypair, and send it to 
your CA. Before that, check the revocation procedure with your CA.


-Ognjen

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



RE: Cannot rid of expired Certificate ...

2012-01-23 Thread Andrew Erskine

-Original Message-
From: Brooke Hedrick [mailto:brooke.t.hedr...@gmail.com] 
Sent: 20 January 2012 12:50
To: Tomcat Users List
Subject: RE: Cannot rid of expired Certificate ...

On Jan 20, 2012 6:47 AM, "Brooke Hedrick" 
wrote:
>
> H
>
> On Jan 20, 2012 4:23 AM, "Andrew Erskine"  wrote:
> >
> > Top post ?
> >
> > Win2003svr
> >
> > Yes correct store .. the only one I've been using .. did try and 
> > clear
the cache on firefox will try ie
> >
> > Thanks.
> > -Original Message-
> > From: Pid [mailto:p...@pidster.com]
> > Sent: 20 January 2012 09:51
> > To: Tomcat Users List
> > Subject: Re: Cannot rid of expired Certificate ...
> >
> > On 20/01/2012 02:28, Brooke Hedrick wrote:
> > > Are you sure you updated the correct keystore?  Which o/s are you
running?
> >
> > (Please don't top post.)
> >
> > It's worth noting that some browsers appear to cache certs and
sometimes changes are not immediately apparent.
> >
> >
> > p
> >
> > > On Jan 19, 2012 2:54 PM, "Darryl Lewis" 
wrote:
> > >
> > >> Did you restart tomcat?
> > >>
> > >> On 20/01/12 5:00 AM, "Andrew Erskine"  wrote:
> > >>
> > >>> I have a self certificate that expired today.
> > >>>
> > >>>
> > >>>
> > >>> I removed the certificate from the keystore which the server.xml 
> > >>> is pointin= g at and generated a new one with the same alias and 
> > >>> I can see that cert in=  the keystore.
> > >>>
> > >>>
> > >>>
> > >>> I've been through all my certificate locations on firefox and 
> > >>> removed any i= nstance
> > >>>
> > >>>
> > >>>
> > >>> On restarting tomcat and starting a new browser the website is 
> > >>> still saying=  I have an expired certificate - so where is this 
> > >>> being picked up
> > >> >from ? an= d is there a step I'm missing ?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Thanks.
> > >>>
> > >>
> > >>
> > >> -
> > >>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > >> For additional commands, e-mail: users-h...@tomcat.apache.org
> > >>
> > >>
> > >
> >
> >
> > --
> >
> > [key:62590808]
> >
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> Where is your keystore located?  When running on with Tomcat poviding 
> the
cert, as I recall, there were 2 options of keystore placement.  If you are 
using APR you can specify the location.  If not, it assumes it has to look 
under your 'profile' home.  So, c:/documents ands settings/... or c:/users/...  
Are you using APR?

Another question...  To rule out the browser, have you tried using openssl to 
retrieve tthe certificate?

The only placement of my keystore is ..

keystoreFile="/custom/keystore/cacerts"
keystorePass="changeit">

and that is where I have deleted the entry for my server and re-created a new 
one.

Not sure what APR is ?

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



Re: Cannot rid of expired Certificate ...

2012-01-23 Thread André Warnier

Andrew Erskine wrote:
...


Not sure what APR is ?


To save someone else the time :

See : http://apr.apache.org/

In essence, "APR" is a software library which contains a number of TCP-socket-related 
functions which /can/ be used by software applications (such as Apache httpd and Tomcat), 
as a replacement for similar platform-specific functions, to provide more uniformity.


In the case of Tomcat : by default, Tomcat, for its Connectors, uses the network-related 
functions provided by the Java JVM (e.g., to open a listening socket for a Connector). 
However, if Tomcat detects the availability of the APR library when it starts, it will 
switch to using this library instead.

The APR implementation is supposed to be more efficient and faster.

The importance of this, in the current context, is that there is a difference regarding 
SSL (HTTPS) : the standard JVM functions use the Java JVM's implementation of SSL, while 
APR functions use the OpenSSL library.  This matters because the relevant Connector 
attributes are different in each case (and also probably where the software looks for 
"things" like keystore etc..).


You can see if on your system Tomcat has found (and is using) the APR library or not, by 
examining the Tomcat logfiles : at startup, Tomcat will print a warning if it did not find 
APR.




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



RE: Cannot rid of expired Certificate ...

2012-01-23 Thread Andrew Erskine
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: 23 January 2012 10:46
To: Tomcat Users List
Subject: Re: Cannot rid of expired Certificate ...

Andrew Erskine wrote:
...
>
> Not sure what APR is ?
>
To save someone else the time :

See : http://apr.apache.org/

In essence, "APR" is a software library which contains a number of 
TCP-socket-related functions which /can/ be used by software applications (such 
as Apache httpd and Tomcat), as a replacement for similar platform-specific 
functions, to provide more uniformity.

In the case of Tomcat : by default, Tomcat, for its Connectors, uses the 
network-related functions provided by the Java JVM (e.g., to open a listening 
socket for a Connector).
However, if Tomcat detects the availability of the APR library when it starts, 
it will switch to using this library instead.
The APR implementation is supposed to be more efficient and faster.

The importance of this, in the current context, is that there is a difference 
regarding SSL (HTTPS) : the standard JVM functions use the Java JVM's 
implementation of SSL, while APR functions use the OpenSSL library.  This 
matters because the relevant Connector attributes are different in each case 
(and also probably where the software looks for "things" like keystore etc..).

You can see if on your system Tomcat has found (and is using) the APR library 
or not, by examining the Tomcat logfiles : at startup, Tomcat will print a 
warning if it did not find APR.

So I've deleted my certificate again and created a new certificate ..

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
spectrum-92, Jan 19, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92
Enter keystore password:

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg 
RSA -keystore d:\win32app\Spectrum\custom\keystore
keytool error: java.lang.Exception: Keystore file exists, but is empty: 
d:\win32app\Spectrum\custom\keystore

D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg 
RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:
What is your first and last name?
  [Unknown]:  spectrum-92
What is the name of your organizational unit?
  [Unknown]:
What is the name of your organization?
  [Unknown]:
What is the name of your City or Locality?
  [Unknown]:
What is the name of your State or Province?
  [Unknown]:
What is the two-letter country code for this unit?
  [Unknown]:
Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown 
correct?
  [no]:  yes

Enter key password for 
(RETURN if same as keystore password):

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
spectrum-92, Jan 23, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): 8F:26:60:6B:9E:01:64:5E:CB:73:8A:BC:4E:3E:AF:AB
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>

Heres my server.xml ..



 

Reboot tomcat (stdout.log)

Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - 
(INFO) - Initializing Coyote HTTP/1.1 on http-80
Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - 
(INFO) - Initializing Coyote HTTP/1.1 on http-443
Jan 23, 2012 10:58:39 AM (m

Re: Cannot rid of expired Certificate ...

2012-01-23 Thread André Warnier

Andrew Erskine wrote:

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: 23 January 2012 10:46
To: Tomcat Users List
Subject: Re: Cannot rid of expired Certificate ...

Andrew Erskine wrote:
...

Not sure what APR is ?


To save someone else the time :

See : http://apr.apache.org/

In essence, "APR" is a software library which contains a number of 
TCP-socket-related functions which /can/ be used by software applications (such as Apache 
httpd and Tomcat), as a replacement for similar platform-specific functions, to provide 
more uniformity.

In the case of Tomcat : by default, Tomcat, for its Connectors, uses the 
network-related functions provided by the Java JVM (e.g., to open a listening 
socket for a Connector).
However, if Tomcat detects the availability of the APR library when it starts, 
it will switch to using this library instead.
The APR implementation is supposed to be more efficient and faster.

The importance of this, in the current context, is that there is a difference regarding 
SSL (HTTPS) : the standard JVM functions use the Java JVM's implementation of SSL, while 
APR functions use the OpenSSL library.  This matters because the relevant Connector 
attributes are different in each case (and also probably where the software looks for 
"things" like keystore etc..).

You can see if on your system Tomcat has found (and is using) the APR library 
or not, by examining the Tomcat logfiles : at startup, Tomcat will print a 
warning if it did not find APR.

So I've deleted my certificate again and created a new certificate ..

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
spectrum-92, Jan 19, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92
Enter keystore password:

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg 
RSA -keystore d:\win32app\Spectrum\custom\keystore
keytool error: java.lang.Exception: Keystore file exists, but is empty: 
d:\win32app\Spectrum\custom\keystore

D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg 
RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:
What is your first and last name?
  [Unknown]:  spectrum-92
What is the name of your organizational unit?
  [Unknown]:
What is the name of your organization?
  [Unknown]:
What is the name of your City or Locality?
  [Unknown]:
What is the name of your State or Province?
  [Unknown]:
What is the two-letter country code for this unit?
  [Unknown]:
Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown 
correct?
  [no]:  yes

Enter key password for 
(RETURN if same as keystore password):

D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore 
d:\win32app\Spectrum\custom\keystore\cacerts
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

root, Oct 21, 2011, trustedCertEntry,
Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
spectrum-92, Jan 23, 2012, PrivateKeyEntry,
Certificate fingerprint (MD5): 8F:26:60:6B:9E:01:64:5E:CB:73:8A:BC:4E:3E:AF:AB
tomcatss1, Oct 21, 2011, PrivateKeyEntry,
Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB

D:\win32app\Spectrum\Java\jre\bin>

Heres my server.xml ..



 

Reboot tomcat (stdout.log)

Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - 
(INFO) - Initializing Coyote HTTP/1.1 on http-80
Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - 
(INFO) - Initializing Coyote HTTP/1.1 on http-443
Jan 23

Re: Tomcat 6.0.35-SocketException: Too many open files issue with

2012-01-23 Thread gnath
Hello Robert, 


We are talking about an app which has been grown since years and now migrated 
to Tomcat. Most of the main code is migrated to use spring jdbc and spring 3.0 
mvc. Would you recommend some way that i can spot the issue from inspecting the 
open file descriptors once the server hangs/crashes so that i can check the 
code to see what you are saying? Please do let me know.


All, please help if you can give me any hints from the information i provided 
down below.


Thanks
-G




 From: Purvis Robert (NHS CONNECTING FOR HEALTH) 
To: Tomcat Users List ; gnath 
 
Sent: Monday, January 23, 2012 1:32 AM
Subject: RE: Tomcat 6.0.35-SocketException: Too many open files  issue with
 
Sorry to possibly state the obvious, but are there perhaps files that are not 
being closed?

This can often happen if code goes into a "catch", and a file is not closed. 
Best to have a "finally" block which checks if a file is open, and closes it.


Robert Purvis

-Original Message-
From: gnath [mailto:gautam_exquis...@yahoo.com]
Sent: 22 January 2012 08:01
To: users@tomcat.apache.org
Subject: Tomcat 6.0.35-SocketException: Too many open files issue with

Hello,

We have been seeing "SocketException: Too many open files" in production 
environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day and 
requires a restart of Tomcat. When this happened for the first time, we 
searched online and found people suggesting to increase the file descriptors 
size and we increased to 4096. But still the problem persists.  We have the 
Orion App Server also running on the same machine but usually during the day 
when we check the open file descriptor by command: ls -l /proc/PID/fd, its 
always less than 1000 combined  for both Orion and Tomcat.


Here is the exception we see pouring in the logs once it starts: This requires 
us to kill java process and restart tomcat. Our Tomcat configuration 
maxThreadCount is 500 with minSpareThreads=50 in server.xml


SEVERE: Socket accept failed
java.net.SocketException: Too many open files
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
        at java.net.ServerSocket.implAccept(ServerSocket.java:462)
        at java.net.ServerSocket.accept(ServerSocket.java:430)
        at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352)
        at java.lang.Thread.run(Thread.java:662)

ulimit -a gives for the user where Tomcat is running.


open files                      (-n) 4096


Please let me know what could be the issue here and how can i resolve this 'Too 
many open files' issue.

Thanks
-G



This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail



Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread gnath
Hi all, 


We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
have configured to use tomcatThreadPool with maxThreads=500 and 
minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have 
two connectors (http and ssl) It has been giving some problems like 'too many 
open files' or just hangs once in a while which requires a restart to get back 
to normal. 


Recently i happened to check our access logs when the server hung and stopped 
responding. We were printing the thread number in the logs and i have seen the 
number going upto 770 (though the max is configured at 500). I was under 
impression that the threads will be shared among the connectors and max it can 
go to 500. Could you please explain why im seeing very high number than 
configured? Is that maxThreads value per connector?

Thanks
-G


Re: Tomcat 6.0.35-SocketException: Too many open files issue with

2012-01-23 Thread Daniel Mikusa
On Mon, 2012-01-23 at 05:33 -0800, gnath wrote:
> Hello Robert, 
> 
> 
> We are talking about an app which has been grown since years and now migrated 
> to Tomcat. Most of the main code is migrated to use spring jdbc and spring 
> 3.0 mvc. 
> Would you recommend some way that i can spot the issue from inspecting the 
> open file descriptors once the server hangs/crashes so that i can check the 
> code to see what you are saying? Please do let me know.

Try running FindBugs on your code.  In most cases, it will detect when
you do not correctly close a file.

Dan


> 
> 
> All, please help if you can give me any hints from the information i provided 
> down below.
> 
> 
> Thanks
> -G
> 
> 
> 
> 
>  From: Purvis Robert (NHS CONNECTING FOR HEALTH) 
> To: Tomcat Users List ; gnath 
>  
> Sent: Monday, January 23, 2012 1:32 AM
> Subject: RE: Tomcat 6.0.35-SocketException: Too many open files  issue with
>  
> Sorry to possibly state the obvious, but are there perhaps files that are not 
> being closed?
> 
> This can often happen if code goes into a "catch", and a file is not closed. 
> Best to have a "finally" block which checks if a file is open, and closes it.
> 
> 
> Robert Purvis
> 
> -Original Message-
> From: gnath [mailto:gautam_exquis...@yahoo.com]
> Sent: 22 January 2012 08:01
> To: users@tomcat.apache.org
> Subject: Tomcat 6.0.35-SocketException: Too many open files issue with
> 
> Hello,
> 
> We have been seeing "SocketException: Too many open files" in production 
> environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day 
> and requires a restart of Tomcat. When this happened for the first time, we 
> searched online and found people suggesting to increase the file descriptors 
> size and we increased to 4096. But still the problem persists.  We have the 
> Orion App Server also running on the same machine but usually during the day 
> when we check the open file descriptor by command: ls -l /proc/PID/fd, its 
> always less than 1000 combined  for both Orion and Tomcat.
> 
> 
> Here is the exception we see pouring in the logs once it starts: This 
> requires us to kill java process and restart tomcat. Our Tomcat configuration 
> maxThreadCount is 500 with minSpareThreads=50 in server.xml
> 
> 
> SEVERE: Socket accept failed
> java.net.SocketException: Too many open files
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
> at java.net.ServerSocket.implAccept(ServerSocket.java:462)
> at java.net.ServerSocket.accept(ServerSocket.java:430)
> at 
> org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352)
> at java.lang.Thread.run(Thread.java:662)
> 
> ulimit -a gives for the user where Tomcat is running.
> 
> 
> open files  (-n) 4096
> 
> 
> Please let me know what could be the issue here and how can i resolve this 
> 'Too many open files' issue.
> 
> Thanks
> -G
> 
> 
> 
> This message may contain confidential information. If you are not the 
> intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-mail or take 
> any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
> 
> Thank you for your co-operation.
> 
> NHSmail is the secure email and directory service available for all NHS staff 
> in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive 
> information with NHSmail and GSi recipients
> NHSmail provides an email address for your career in the NHS and can be 
> accessed anywhere
> For more information and to find out how you can switch, visit 
> www.connectingforhealth.nhs.uk/nhsmail
> 
> 


Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread Daniel Mikusa
On Mon, 2012-01-23 at 05:44 -0800, gnath wrote:
> Hi all, 
> 
> 
> We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
> have configured to use tomcatThreadPool with maxThreads=500 and 
> minSpareThreads=50 with default connectionTimeout(which is 6 sec). 

> We have two connectors (http and ssl) It has been giving some problems like 
> 'too many open files' or just hangs once in a while which requires a restart 
> to get back to normal. 

Have you taken any thread dumps when the server hangs?  What do you see?

> 
> 
> Recently i happened to check our access logs when the server hung and stopped 
> responding. We were printing the thread number in the logs and i have seen 
> the number going upto 770 (though the max is configured at 500). I was under 
> impression that the threads will be shared among the connectors and max it 
> can go to 500. Could you please explain why im seeing very high number than 
> configured? Is that maxThreads value per connector?

It would help to see how you have your thread pool and connectors
configured.  Please attach your server.xml minus any comments.

Also, a thread dump would be nice to confirm how many threads were
actually running.

Dan


Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread André Warnier

gnath wrote:
Hi all, 



We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
have configured to use tomcatThreadPool with maxThreads=500 and 
minSpareThreads=50 with default connectionTimeout(which is 6 sec).


Which would be about 16 hours.  I am not sure of the meaning of connectionTimeout in this 
context, but that value seems to me so large as to be pretty useless for any practical 
timeout I can imagine.



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



Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread Pid
On 23/01/2012 14:06, Daniel Mikusa wrote:
> On Mon, 2012-01-23 at 05:44 -0800, gnath wrote:
>> Hi all, 
>>
>>
>> We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
>> have configured to use tomcatThreadPool with maxThreads=500 and 
>> minSpareThreads=50 with default connectionTimeout(which is 6 sec). 
> 
>> We have two connectors (http and ssl) It has been giving some problems like 
>> 'too many open files' or just hangs once in a while which requires a restart 
>> to get back to normal. 
> 
> Have you taken any thread dumps when the server hangs?  What do you see?
> 
>>
>>
>> Recently i happened to check our access logs when the server hung and 
>> stopped responding. We were printing the thread number in the logs and i 
>> have seen the number going upto 770 (though the max is configured at 500). I 
>> was under impression that the threads will be shared among the connectors 
>> and max it can go to 500. Could you please explain why im seeing very high 
>> number than configured? Is that maxThreads value per connector?
> 
> It would help to see how you have your thread pool and connectors
> configured.  Please attach your server.xml minus any comments.
> 
> Also, a thread dump would be nice to confirm how many threads were
> actually running.

The maxThreads in the Connector only applies to Tomcat request
processing threads, it is not a limit imposed on the whole JVM.

You will usually have 20-30 threads running doing various things in
addition to those that your app starts.

If Tomcat is at 500 + 20 then the rest are likely to be started by your
application or dependencies.  As Dan states, a thread dump is the way to
understand this.


p





-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature


Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread André Warnier

André Warnier wrote:

gnath wrote:

Hi all,

We have Tomcat 6.0.35 in our production Environment running on Linux, 
and we have configured to use tomcatThreadPool with maxThreads=500 and 
minSpareThreads=50 with default connectionTimeout(which is 6 sec).


Which would be about 16 hours.  I am not sure of the meaning of 
connectionTimeout in this context, but that value seems to me so large 
as to be pretty useless for any practical timeout I can imagine.




After checking the docs, that value is in milliseconds, not seconds :

connectionTimeout   

The number of milliseconds this Connector will wait, after accepting a connection, for the 
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) 
timeout. The default value is 6 (i.e. 60 seconds) but note that the standard 
server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds).


That sounds more reasonable.

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



RE: Cannot rid of expired Certificate ...

2012-01-23 Thread Caldarale, Charles R
> From: Andrew Erskine [mailto:a.ersk...@darasoft.com] 
> Subject: RE: Cannot rid of expired Certificate ...

> Heres my server.xml ..

Only part of it, unfortunately.

> port="443" minProcessors="5" maxProcessors="75"

> Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol)
> - (INFO) - Initializing Coyote HTTP/1.1 on http-80
> Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol)
> - (INFO) - Initializing Coyote HTTP/1.1 on http-443

It appears that you also have port 80 configured, you're not using APR, and 
ports 80 and 443 were successfully initialized.

> Jan 23, 2012 10:58:53 AM (main) (org.apache.axis2.transport.http.AxisServlet)
> - (WARN) - No transportReceiver for 
> org.apache.axis2.transport.http.AxisServletListener
> found. An instance for HTTP will be configured automatically. Please update 
> your axis2.xml file!

Looks like your Axis2 configuration is broken.

> Jan 23, 2012 10:58:53 AM (HttpListener-8443-1) 
> (org.apache.axis2.transport.http.server.DefaultConnectionListener)
> - (INFO) - Listening on port 8443

So you have Axis2 listening on 8443 - which is a commonly used HTTPS substitute 
port.

What port are your clients trying to connect to, 443 or 8443?

 - Chuck


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


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



Re: Cannot rid of expired Certificate ...

2012-01-23 Thread Darryl Lewis
Some key authorities recently changed the default from 1024 to 2048 bit
keys.

On some occasions I've been forced to delete my keystore and start from
scratch to make sure there are no unsuitable keys still in there.


On 23/01/12 11:45 PM, "André Warnier"  wrote:

>Andrew Erskine wrote:
>> -Original Message-
>> From: André Warnier [mailto:a...@ice-sa.com]
>> Sent: 23 January 2012 10:46
>> To: Tomcat Users List
>> Subject: Re: Cannot rid of expired Certificate ...
>> 
>> Andrew Erskine wrote:
>> ...
>>> Not sure what APR is ?
>>>
>> To save someone else the time :
>> 
>> See : http://apr.apache.org/
>> 
>> In essence, "APR" is a software library which contains a number of
>>TCP-socket-related functions which /can/ be used by software
>>applications (such as Apache httpd and Tomcat), as a replacement for
>>similar platform-specific functions, to provide more uniformity.
>> 
>> In the case of Tomcat : by default, Tomcat, for its Connectors, uses
>>the network-related functions provided by the Java JVM (e.g., to open a
>>listening socket for a Connector).
>> However, if Tomcat detects the availability of the APR library when it
>>starts, it will switch to using this library instead.
>> The APR implementation is supposed to be more efficient and faster.
>> 
>> The importance of this, in the current context, is that there is a
>>difference regarding SSL (HTTPS) : the standard JVM functions use the
>>Java JVM's implementation of SSL, while APR functions use the OpenSSL
>>library.  This matters because the relevant Connector attributes are
>>different in each case (and also probably where the software looks for
>>"things" like keystore etc..).
>> 
>> You can see if on your system Tomcat has found (and is using) the APR
>>library or not, by examining the Tomcat logfiles : at startup, Tomcat
>>will print a warning if it did not find APR.
>> 
>> So I've deleted my certificate again and created a new certificate ..
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore
>>d:\win32app\Spectrum\custom\keystore\cacerts
>> Enter keystore password:
>> 
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 4 entries
>> 
>> root, Oct 21, 2011, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
>> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
>> spectrum-92, Jan 19, 2012, PrivateKeyEntry,
>> Certificate fingerprint (MD5):
>>DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E
>> tomcatss1, Oct 21, 2011, PrivateKeyEntry,
>> Certificate fingerprint (MD5):
>>DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore
>>d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92
>> Enter keystore password:
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore
>>d:\win32app\Spectrum\custom\keystore\cacerts
>> Enter keystore password:
>> 
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 3 entries
>> 
>> root, Oct 21, 2011, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
>> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
>> tomcatss1, Oct 21, 2011, PrivateKeyEntry,
>> Certificate fingerprint (MD5):
>>DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92
>>-keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore
>> keytool error: java.lang.Exception: Keystore file exists, but is empty:
>>d:\win32app\Spectrum\custom\keystore
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92
>>-keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts
>> Enter keystore password:
>> What is your first and last name?
>>   [Unknown]:  spectrum-92
>> What is the name of your organizational unit?
>>   [Unknown]:
>> What is the name of your organization?
>>   [Unknown]:
>> What is the name of your City or Locality?
>>   [Unknown]:
>> What is the name of your State or Province?
>>   [Unknown]:
>> What is the two-letter country code for this unit?
>>   [Unknown]:
>> Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown,
>>C=Unknown correct?
>>   [no]:  yes
>> 
>> Enter key password for 
>> (RETURN if same as keystore password):
>> 
>> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore
>>d:\win32app\Spectrum\custom\keystore\cacerts
>> Enter keystore password:
>> 
>> Keystore type: JKS
>> Keystore provider: SUN
>> 
>> Your keystore contains 4 entries
>> 
>> root, Oct 21, 2011, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A
>> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry,
>> Certificate fingerprint (MD5):
>>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80
>> spectrum-92, Jan 2

Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread gnath
Thanks Dan and p

Sure, i will collect the thread dump once it happens again. Mean while here my 
server.xml content related to executor and connectors:



    

    

I understand what you are saying regarding the application owned threads, but 
do they show in the access logs with the prefix i mentioned for 
tomcatThreadPool (i saw in access logs as catalina-exec-770) ?

Please let me know if im missing anything or doing anything wrong in my 
configuration. 
 I will check on the thread dump once i collect it.

Thanks
-G




 From: Pid 
To: Tomcat Users List  
Sent: Monday, January 23, 2012 6:12 AM
Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
 
On 23/01/2012 14:06, Daniel Mikusa wrote:
> On Mon, 2012-01-23 at 05:44 -0800, gnath wrote:
>> Hi all, 
>>
>>
>> We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
>> have configured to use tomcatThreadPool with maxThreads=500 and 
>> minSpareThreads=50 with default connectionTimeout(which is 6 sec). 
> 
>> We have two connectors (http and ssl) It has been giving some problems like 
>> 'too many open files' or just hangs once in a while which requires a restart 
>> to get back to normal. 
> 
> Have you taken any thread dumps when the server hangs?  What do you see?
> 
>>
>>
>> Recently i happened to check our access logs when the server hung and 
>> stopped responding. We were printing the thread number in the logs and i 
>> have seen the number going upto 770 (though the max is configured at 500). I 
>> was under impression that the threads will be shared among the connectors 
>> and max it can go to 500. Could you please explain why im seeing very high 
>> number than configured? Is that maxThreads value per connector?
> 
> It would help to see how you have your thread pool and connectors
> configured.  Please attach your server.xml minus any comments.
> 
> Also, a thread dump would be nice to confirm how many threads were
> actually running.

The maxThreads in the Connector only applies to Tomcat request
processing threads, it is not a limit imposed on the whole JVM.

You will usually have 20-30 threads running doing various things in
addition to those that your app starts.

If Tomcat is at 500 + 20 then the rest are likely to be started by your
application or dependencies.  As Dan states, a thread dump is the way to
understand this.


p





-- 

[key:62590808]

Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread gnath


Hi Andre, 

Sorry, my mistake. 


you are right. i actually meant milliseconds. However i checked my 
configuration again and here is what i have :  ( I have the http connector 
configured at 2 ms. and the secured one left at default 6 ms)




    

    


Please let me know if im doing any mistake or missing anything here.

Thanks
-G




 From: André Warnier 
To: Tomcat Users List  
Sent: Monday, January 23, 2012 6:14 AM
Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
 
André Warnier wrote:
> gnath wrote:
>> Hi all,
>> 
>> We have Tomcat 6.0.35 in our production Environment running on Linux, and we 
>> have configured to use tomcatThreadPool with maxThreads=500 and 
>> minSpareThreads=50 with default connectionTimeout(which is 6 sec).
> 
> Which would be about 16 hours.  I am not sure of the meaning of 
> connectionTimeout in this context, but that value seems to me so large as to 
> be pretty useless for any practical timeout I can imagine.
> 

After checking the docs, that value is in milliseconds, not seconds :

connectionTimeout    

The number of milliseconds this Connector will wait, after accepting a 
connection, for the request URI line to be presented. Use a value of -1 to 
indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 
seconds) but note that the standard server.xml that ships with Tomcat sets this 
to 2 (i.e. 20 seconds).

That sounds more reasonable.

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

Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread André Warnier

gnath wrote:


Hi Andre, 

Sorry, my mistake. 



you are right. i actually meant milliseconds. However i checked my 
configuration again and here is what i have :  ( I have the http connector 
configured at 2 ms. and the secured one left at default 6 ms)









Please let me know if im doing any mistake or missing anything here.


On the face of it, you are, or you are prone to typos.
Assuming that when you indicate "http port" above, you mean that this is in reality some 
consistent specific valid port number, then at least one of them is wrong.


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



Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread gnath


Please ignore my previously sent edited configuration. Here is what our 
configurations are without editing them :



    

    

Please let me know. I appreciate your help in looking into this

Thanks
G





 From: André Warnier 
To: Tomcat Users List  
Sent: Monday, January 23, 2012 6:37 AM
Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
 
gnath wrote:
> 
> Hi Andre, 
> Sorry, my mistake. 
> 
> you are right. i actually meant milliseconds. However i checked my 
> configuration again and here is what i have :  ( I have the http connector 
> configured at 2 ms. and the secured one left at default 6 ms)
> 
> 
>                    namePrefix="catalina-exec-"
>                   maxThreads="500"
>                   minSpareThreads="50"/>
> 
>       protocol="HTTP/1.1"
>                connectionTimeout="2"
>                redirectPort="https port" address="ip address"/>
> 
>                     scheme="https" secure="true"
>                clientAuth="false" sslProtocol="TLS" address="ip address"
>                keystoreFile="path to cert" keystorePass="password" />
> 
> 
> Please let me know if im doing any mistake or missing anything here.
> 
On the face of it, you are, or you are prone to typos.
Assuming that when you indicate "http port" above, you mean that this is in 
reality some consistent specific valid port number, then at least one of them 
is wrong.

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

Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread Daniel Mikusa
On Mon, 2012-01-23 at 06:24 -0800, gnath wrote:
> Thanks Dan and p
> 
> Sure, i will collect the thread dump once it happens again. Mean while here 
> my server.xml content related to executor and connectors:
> 
>namePrefix="catalina-exec-"
>   maxThreads="500"
>   minSpareThreads="50"/>
> 
> connectionTimeout="2"
>redirectPort="https port" address="ip address"/>
> 
> scheme="https" secure="true"
>clientAuth="false" sslProtocol="TLS" address="ip address"
>keystoreFile="path to cert" keystorePass="password" />
> 
> I understand what you are saying regarding the application owned threads, but 
> do they show in the access logs with the prefix i mentioned for 
> tomcatThreadPool (i saw in access logs as catalina-exec-770) ?

I do not believe that a thread with the name "catalina-exec-770" means
that there are 770 active threads.  It means that the thread you are
looking at is number 770.  The "770" is just an identifier.

>From the docs for Executor:  "The name prefix for each thread created by
the executor. The thread name for an individual thread will be
namePrefix+threadNumber".

You can get a count of the threads being used by your executor with the
following command:

  jstack  | grep "catalina-exec-" | wc


Dan

> 
> Please let me know if im missing anything or doing anything wrong in my 
> configuration. 
>  I will check on the thread dump once i collect it.
> 
> Thanks
> -G
> 
> 
> 
> 
>  From: Pid 
> To: Tomcat Users List  
> Sent: Monday, January 23, 2012 6:12 AM
> Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
>  
> On 23/01/2012 14:06, Daniel Mikusa wrote:
> > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote:
> >> Hi all, 
> >>
> >>
> >> We have Tomcat 6.0.35 in our production Environment running on Linux, and 
> >> we have configured to use tomcatThreadPool with maxThreads=500 and 
> >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). 
> > 
> >> We have two connectors (http and ssl) It has been giving some problems 
> >> like 'too many open files' or just hangs once in a while which requires a 
> >> restart to get back to normal. 
> > 
> > Have you taken any thread dumps when the server hangs?  What do you see?
> > 
> >>
> >>
> >> Recently i happened to check our access logs when the server hung and 
> >> stopped responding. We were printing the thread number in the logs and i 
> >> have seen the number going upto 770 (though the max is configured at 500). 
> >> I was under impression that the threads will be shared among the 
> >> connectors and max it can go to 500. Could you please explain why im 
> >> seeing very high number than configured? Is that maxThreads value per 
> >> connector?
> > 
> > It would help to see how you have your thread pool and connectors
> > configured.  Please attach your server.xml minus any comments.
> > 
> > Also, a thread dump would be nice to confirm how many threads were
> > actually running.
> 
> The maxThreads in the Connector only applies to Tomcat request
> processing threads, it is not a limit imposed on the whole JVM.
> 
> You will usually have 20-30 threads running doing various things in
> addition to those that your app starts.
> 
> If Tomcat is at 500 + 20 then the rest are likely to be started by your
> application or dependencies.  As Dan states, a thread dump is the way to
> understand this.
> 
> 
> p
> 
> 
> 
> 
> 
> -- 
> 
> [key:62590808]


Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread gnath
Sure i will keep monitoring the Thread count as you said using jstack and keep 
you posted once the server hangs again.

Thanks
-G




 From: Daniel Mikusa 
To: Tomcat Users List ; gnath 
 
Sent: Monday, January 23, 2012 6:44 AM
Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
 
On Mon, 2012-01-23 at 06:24 -0800, gnath wrote:
> Thanks Dan and p
> 
> Sure, i will collect the thread dump once it happens again. Mean while here 
> my server.xml content related to executor and connectors:
> 
>                    namePrefix="catalina-exec-"
>                   maxThreads="500"
>                   minSpareThreads="50"/>
> 
>                     connectionTimeout="2"
>                redirectPort="https port" address="ip address"/>
> 
>                     scheme="https" secure="true"
>                clientAuth="false" sslProtocol="TLS" address="ip address"
>                keystoreFile="path to cert" keystorePass="password" />
> 
> I understand what you are saying regarding the application owned threads, but 
> do they show in the access logs with the prefix i mentioned for 
> tomcatThreadPool (i saw in access logs as catalina-exec-770) ?

I do not believe that a thread with the name "catalina-exec-770" means
that there are 770 active threads.  It means that the thread you are
looking at is number 770.  The "770" is just an identifier.

>From the docs for Executor:  "The name prefix for each thread created by
the executor. The thread name for an individual thread will be
namePrefix+threadNumber".

You can get a count of the threads being used by your executor with the
following command:

  jstack  | grep "catalina-exec-" | wc


Dan

> 
> Please let me know if im missing anything or doing anything wrong in my 
> configuration. 
>  I will check on the thread dump once i collect it.
> 
> Thanks
> -G
> 
> 
> 
> 
>  From: Pid 
> To: Tomcat Users List  
> Sent: Monday, January 23, 2012 6:12 AM
> Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count
>  
> On 23/01/2012 14:06, Daniel Mikusa wrote:
> > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote:
> >> Hi all, 
> >>
> >>
> >> We have Tomcat 6.0.35 in our production Environment running on Linux, and 
> >> we have configured to use tomcatThreadPool with maxThreads=500 and 
> >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). 
> > 
> >> We have two connectors (http and ssl) It has been giving some problems 
> >> like 'too many open files' or just hangs once in a while which requires a 
> >> restart to get back to normal. 
> > 
> > Have you taken any thread dumps when the server hangs?  What do you see?
> > 
> >>
> >>
> >> Recently i happened to check our access logs when the server hung and 
> >> stopped responding. We were printing the thread number in the logs and i 
> >> have seen the number going upto 770 (though the max is configured at 500). 
> >> I was under impression that the threads will be shared among the 
> >> connectors and max it can go to 500. Could you please explain why im 
> >> seeing very high number than configured? Is that maxThreads value per 
> >> connector?
> > 
> > It would help to see how you have your thread pool and connectors
> > configured.  Please attach your server.xml minus any comments.
> > 
> > Also, a thread dump would be nice to confirm how many threads were
> > actually running.
> 
> The maxThreads in the Connector only applies to Tomcat request
> processing threads, it is not a limit imposed on the whole JVM.
> 
> You will usually have 20-30 threads running doing various things in
> addition to those that your app starts.
> 
> If Tomcat is at 500 + 20 then the rest are likely to be started by your
> application or dependencies.  As Dan states, a thread dump is the way to
> understand this.
> 
> 
> p
> 
> 
> 
> 
> 
> -- 
> 
> [key:62590808]

Restarting tomcat 7.0.23 on MAC OS X 10.6

2012-01-23 Thread Oliver Due Billing
I hope somebody can help me.

I have a test-server on my macbook pro and it takes forever to restart the
server do anyone have a clue to whats happening. I have run the
configuration just fine on a windows laptop.

It also takes forever with the default configuration.

I just the following guide
http://wolfpaulus.com/journal/mac/tomcat7

-- 
*Oliver Billing*
*Developer*

watAgame ApS
Kigkurren 8D, 1st
2300 Copenhagen S
Denmark

office   +45 3536 4110
direct   +45 8833 6288
mobile +45 2087 7341

o...@watagame.com
www.goSupermodel.com
www.watAgame.com


Re: CVE-2012-0022 details

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 1/22/12 5:08 PM, ma...@apache.org wrote:
> Christopher Schultz  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> David,
>> 
>> On 1/21/12 3:02 AM, David Jorm wrote:
>>> Based on reading the advisory and Tomcat patch code, it seems
>>> to me that the issue is simply slow processing when a very
>>> large number of parameters is received with a request.
>> 
>> The parameter names must have colliding hash code values in order
>> to exercise this particular vulnerability. Otherwise, large
>> numbers of request parameters is merely a potential memory
>> exhaustion vulnerability (which is a different issue).
> 
> No, no, no. That is completely wrong. CVE-2012-0022 is solely about
> the number of parameters and NOTHING TO DO WITH HASH COLLISIONS.

Sorry, the last time I looked-up CVE-2012-0022 it said that it was
just a placeholder which I assumed was being held in reserve for the
hash-collision bug. I see now that the data has been updated and it
even includes a note that it's NOT CVE-2011-4858.

Sorry for the noise.

- -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/

iEYEARECAAYFAk8dgCcACgkQ9CaO5/Lv0PB2LQCdGnDpbrD6zsjpeaQY6RdcCmgQ
xHoAnRvInr0xIs7srQuXsJOdL+aggSxN
=eJc3
-END PGP SIGNATURE-

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



Re: Tomcat 6.0.35-SocketException: Too many open files issue with

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

G,

On 1/22/12 6:18 PM, gnath wrote:
> We have 2 connectors (one for http and another for https) using
> the tomcatThreadPool. I have the connectionTimeout="2" for
> http connector.  However i was told that our https connector might
> not be used by the app as our loadbalancer is handling all the
> https traffic and just sending them to http connector.

You might want to disable that HTTPS connector, but it's probably not
hurting you at all in this case -- just a bit of wasted resources. If
you are sharing a thread pool then there is no negative impact on the
number of threads and/or open files that you have to deal with, here.

> the ulimit settings were increased from default 1024 to 4096 by
> our admin. not sure how he did that, but i see the count as 4096
> when i do ulimit -a.

Well, if your admin says it's right, I suppose it's right.

> for ulimit -n i see its 'unlimited'.

That's good.

> for cat /proc/PID/limits, i get the following response:
> 
> Limit Soft Limit   Hard Limit
> Units Max cpu time  unlimitedunlimited
> seconds Max file size unlimitedunlimited
> bytes Max data size unlimitedunlimited
> bytes Max stack size10485760 unlimited
> bytes Max core file size0unlimited
> bytes Max resident set  unlimitedunlimited
> bytes Max processes unlimitedunlimited
> processes Max open files4096 4096
> files Max locked memory 3276832768
> bytes Max address space unlimitedunlimited
> bytes Max file locksunlimitedunlimited
> locks Max pending signals   202752   202752
> signals Max msgqueue size 819200   819200
> bytes Max nice priority 00
>  Max realtime priority 00

Those all look good to me.

> This morning Tomcat hung again but this time it dint say 'too many 
> open files' in logs but i only see this below in catalina.out:
> 
> org.apache.tomcat.util.http.Parameters processParameters INFO:
> Invalid chunk starting at byte [0] and ending at byte [0] with a
> value of [null] ignored Jorg.apache.tomcat.util.http.Parameters
> processParameters INFO: Invalid chunk starting at byte [0] and
> ending at byte [0] with a value of [null] ignored

Hmm...

> When it hung(java process is still up), i ran few commands like
> lsof by PID and couple others.

Next time, take a thread dump as well. The fact that Tomcat hung up
without an OS problem (like Too Many Open Files) is probably not good.
If this happens again with an apparent hang with no stack traces in
the logs, take a thread dump and post it back here under a different
subject.

> here is what i got:
> 
> lsof -p PID| wc -l 1342
> 
> lsof | wc -l 4520
> 
> lsof -u USER| wc -l 1953

Hmm I wonder if you are hitting a *user* or even *system* limit of
some kind (though a *NIX system with a hard limit of ~4500 file
descriptors seems entirely unreasonable). I also wonder how many
/processes/ and/or /threads/ you have running at once.

> After i kill java process the lsof for pid returned obviously to
> zero

Of course.

> Is there any chance that the tomcat is ignoring the ulimit?

Those limits are not self-imposed: the OS imposes those limits. Tomcat
doesn't even know it's own ulimit (of any kind), so it will simply
consume whatever resources you have configured it to use, and if it
hits a limit, the JVM will experience some kind of OS-related error.

> , some people on web were saying something about setting this in
> catalina.sh.

Setting what? ulimit? I'd do it in setenv.sh because that's a more
appropriate place for that kind of thing. I'm also interested in what
the Internet has to say about what setting(s) to use.

> Please help with my ongoing issue.. its getting very hard to
> monitor the logs every minute and restarting whenever it hangs with
> these kind of issues. I very much appreciate your help in this.

Did this just start happening recently? Perhaps with an upgrade of
some component?

If you think this might actually be related to the number of file
handles being used by your thread pool, you might want to reduce the
maximum number of threads for that thread pool: a slightly less
responsive site is better than one that goes down all the time because
of hard resource limits.

- -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/

iEYEARECAAYFAk8dghAACgkQ9CaO5/Lv0PCmKQCfUaYfeoSkTRDKBppR4ZGFTWgI
8dEAoKgwy1BcKO6bC8nbbLWd6hn0a38N
=TZCu
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additi

Re: Restarting tomcat 7.0.23 on MAC OS X 10.6

2012-01-23 Thread Daniel Mikusa

On Mon, 2012-01-23 at 07:41 -0800, Oliver Due Billing wrote:
> I hope somebody can help me.
> 
> I have a test-server on my macbook pro and it takes forever to restart the
> server do anyone have a clue to whats happening. 

What is the exact version of Java & Tomcat?  Also, how many applications
do you have deployed?

> I have run the configuration just fine on a windows laptop.

Can we assume that these are the exact same installations?  i.e. same
version of Java and Tomcat?  Also, the exact same configuration files
(to the character)?

> 
> It also takes forever with the default configuration.

So, you unzip Tomcat, run "bin/start.sh" and it takes forever to start?
No custom applications deployed and no changes to any configuration
files?


Dan


Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread André Warnier

gnath wrote:


Please ignore my previously sent edited configuration. Here is what our 
configurations are without editing them :







Please let me know. I appreciate your help in looking into this

I have not gone back to your first message, but from the subject I guess that your concern 
is that you think that there are a lot of threads active in Tomcat, as compared to the 
number of HTTP requests that your server is receiving.
The following does not in any way mean that you should not follow the other advices, and 
verify your assumptions, using the appropriate tools.

But you may also want to have a look at the Connector's keep-alive setting.

connectionTimeout   

The number of milliseconds this Connector will wait, after accepting a connection, for the 
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) 
timeout. The default value is 6 (i.e. 60 seconds) but note that the standard 
server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds).


keepAliveTimeout

The number of milliseconds this Connector will wait for another HTTP request before 
closing the connection. The default value is to use the value that has been set for the 
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.



In your configuration, you do not use an explicit keepAliveTimeout attribute, so it 
defaults to the connectionTimeout, which is 20 seconds.


Imagine that your server receives requests for pages, at the rate of 10 per 
second.
And that each page contains 3 embedded thumbnail images.  So after the first request for 
the page, the browser is going to issue 3 more requests for the embedded images.
By default, the keep-alive is active, which means that this all happens over the same HTTP 
(or HTTPS) connection; and since it all happens over the same established connection, it 
will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, 
because it avoids having to tear down and rebuild connections and threads for each request.


Processing the 4 consecutive requests of the browser is likely to take only a fraction of 
a second altogether.
After these 4 requests are served, the keepAliveTimeout starts running, and with your 
current settings it does so for 20 seconds.  During these 20 seconds, the thread which has 
processed the 4 requests keeps waiting, in case the browser has any more requests to send 
over the same connection (which it probably has not, because the user is considering his 
next move).
1/10th of a second after the first request, another browser also sends a request. Since 
the first thread is still busy, a new one is allocated.  After a fraction of a second, 
that one goes in keepAliveTimeout. And so on.
So all in all, this scenario is allocating new threads at the rythm of 10 per second; and 
it is only after the first 20 seconds have gone by, that the timeout of the first thread 
expires, that it can close its connection, and return to the pool to process another 
browser request. By that time, according to the above scenario, you have about 200 threads 
waiting in their keep-alive status, and basically not doing anything.


I am not saying that your scenario matches the above, and only you can 
determine that.
But it could explain a high number of threads apparently idle.
So if those idle threads bother you, it may be worth trying an explicit lower 
keepAliveTimeout (e.g. 5 s), and monitor the impact.



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



Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread André Warnier

gnath wrote:


Please ignore my previously sent edited configuration. Here is what our 
configurations are without editing them :







Please let me know. I appreciate your help in looking into this

I have not gone back to your first message, but from the subject I guess that your concern 
is that you think that there are a lot of threads active in Tomcat, as compared to the 
number of HTTP requests that your server is receiving.
The following does not in any way mean that you should not follow the other advices, and 
verify your assumptions, using the appropriate tools.

But you may also want to have a look at the Connector's keep-alive setting.

connectionTimeout   

The number of milliseconds this Connector will wait, after accepting a connection, for the 
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) 
timeout. The default value is 6 (i.e. 60 seconds) but note that the standard 
server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds).


keepAliveTimeout

The number of milliseconds this Connector will wait for another HTTP request before 
closing the connection. The default value is to use the value that has been set for the 
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.



In your configuration, you do not use an explicit keepAliveTimeout attribute, so it 
defaults to the connectionTimeout, which is 20 seconds.


Imagine that your server receives requests for pages, at the rate of 10 per 
second.
And that each page contains 3 embedded thumbnail images.  So after the first request for 
the page, the browser is going to issue 3 more requests for the embedded images.
By default, the keep-alive is active, which means that this all happens over the same HTTP 
(or HTTPS) connection; and since it all happens over the same established connection, it 
will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, 
because it avoids having to tear down and rebuild connections and threads for each request.


Processing the 4 consecutive requests of the browser is likely to take only a fraction of 
a second altogether.
After these 4 requests are served, the keepAliveTimeout starts running, and with your 
current settings it does so for 20 seconds.  During these 20 seconds, the thread which has 
processed the 4 requests keeps waiting, in case the browser has any more requests to send 
over the same connection (which it probably has not, because the user is considering his 
next move).
1/10th of a second after the first request, another browser also sends a request. Since 
the first thread is still busy, a new one is allocated.  After a fraction of a second, 
that one goes in keepAliveTimeout. And so on.
So all in all, this scenario is allocating new threads at the rythm of 10 per second; and 
it is only after the first 20 seconds have gone by, that the timeout of the first thread 
expires, that it can close its connection, and return to the pool to process another 
browser request. By that time, according to the above scenario, you have about 200 threads 
waiting in their keep-alive status, and basically not doing anything.


I am not saying that your scenario matches the above, and only you can 
determine that.
But it could explain a high number of threads apparently idle.
So if those idle threads bother you, it may be worth trying an explicit lower 
keepAliveTimeout (e.g. 5 s), and monitor the impact.



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



RE: Restarting tomcat 7.0.23 on MAC OS X 10.6

2012-01-23 Thread Caldarale, Charles R
> From: Oliver Due Billing [mailto:o...@watagame.com] 
> Subject: Restarting tomcat 7.0.23 on MAC OS X 10.6

> I have a test-server on my macbook pro and it takes forever to
> restart the server do anyone have a clue to whats happening.

It may be collecting entropy.  Take a thread dump, and see what the JVM is 
doing during the pause.

You can try setting

   -Djava.security.egd=file:/dev/./urandom

as a system property.  Note that the apparently extra "/." is required to trick 
the JVM into using the alternate random byte source.

 - Chuck


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


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



Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)

2012-01-23 Thread James Lampert
We're now trying to bring up Tomcat 7 on a V5R4 AS/400, after 
successfully doing so on V6 and V7 boxes. They have Java 6 installed, 
and I'm told that they installed some PTFs over the weekend, but it's 
still crashing on takeoff.


In catalina.sh, we have:
# Java 6 settings if needed 
export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre  
export -s CATALINA_HOME=/wintouch/tomcat
export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true -Djava.version=1.6 -Xms256m -Xmx512m" 

# OS specific support.  $var _must_ be set to either true or false. 
cygwin=false
darwin=false
os400=true  
case "`uname`" in   
CYGWIN*) cygwin=true;;  
Darwin*) darwin=true;;  
OS400*) os400=true;;
esac


and there is definitely a "java" in the
/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin directory, and so far
as I'm aware, all the JARs are present in the right subdirectories of
/wintouch/tomcat, but in catalina.out, I get:
Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/charsets.jar.  
Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/resources.jar. 
Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/rt.jar.
eval: 001-0014 Command /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin/java not found.
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina   
at java.net.URLClassLoader.findClass(URLClassLoader.java:432)   
at java.lang.ClassLoader.loadClass(ClassLoader.java:642)
at java.lang.ClassLoader.loadClass(ClassLoader.java:608)
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236)   
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)   


When I delete catalina.out and try again, I get the same, only starting
from the ClassNotFoundException.

--
JHHL

-
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

2012-01-23 Thread removeps-code
Initially I thought that my RootJDBCRealm might be the problem, but how can 
that be?  RootJDBCRealm extends Tomcat's own JDBCRealm.  It overrides 
authenticate to call super.authenticate and if there are 3 failures (in that 
super.authenticate returns null), then it locks out the user.  So could the 
user of RootJDBCRealm still be a problem?  Thanks.

--- On Mon, 1/23/12, Mark Thomas  wrote:

> From: Mark Thomas 
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List" 
> Date: Monday, January 23, 2012, 12:49 AM
> 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
> > 
> > 
> > 
> >    className="pacific.tomcat.RootJDBCRealm"
> >         
> 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
> 
>

-
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

2012-01-23 Thread Chema
>2012/1/23  :
> Initially I thought that my RootJDBCRealm might be the problem, but how can 
> that be?  RootJDBCRealm extends Tomcat's own JDBCRealm.  It >overrides 
> authenticate to call super.authenticate and if there are 3 failures (in that 
> super.authenticate returns null), then it locks out the user.  So could >the 
> user of RootJDBCRealm still be a problem?  Thanks.


>From Tomcat 7 docs:

"The JDBCRealm is not recommended for production use as it is single
threaded for all authentication and authorization options. Use the
DataSourceRealm instead.
The UserDatabaseRealm is not intended for large-scale installations.
It is intended for small-scale, relatively static environments."

-
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

2012-01-23 Thread Daniel Mikusa
On Mon, 2012-01-23 at 10:21 -0800, removeps-c...@yahoo.com wrote:
> Initially I thought that my RootJDBCRealm might be the problem, but how can 
> that be?  

> RootJDBCRealm extends Tomcat's own JDBCRealm.  It overrides authenticate to 
> call super.authenticate and if there are 3 failures (in that 
> super.authenticate returns null), then it locks out the user.

Sounds a lot like the LockOutRealm.

  https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#LockOutRealm

Any reason you opted not to use it?

Dan

>   So could the user of RootJDBCRealm still be a problem?  Thanks.
> 
> --- On Mon, 1/23/12, Mark Thomas  wrote:
> 
> > From: Mark Thomas 
> > Subject: Re: Connection.close() has already been called during login
> > To: "Tomcat Users List" 
> > Date: Monday, January 23, 2012, 12:49 AM
> > 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
> > > 
> > > 
> > > 
> > >> className="pacific.tomcat.RootJDBCRealm"
> > > 
> > 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
> > 
> > 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


RE: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)

2012-01-23 Thread Caldarale, Charles R
> From: James Lampert [mailto:jam...@touchtonecorp.com] 
> Subject: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . 
> crash-on-takeoff)

> In catalina.sh, we have:
> > # Java 6 settings if needed 
> > 
> > export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre  
> > 
> > export -s CATALINA_HOME=/wintouch/tomcat
> > 
> > export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true 
> > -Djava.version=1.6 -Xms256m -Xmx512m" 

It's considered bad form to modify catalina.sh; create a setenv.sh script and 
put your environment changes there.

> # OS specific support.  $var _must_ be set to either true or false.   
>   
> os400=true

Why was it necessary to force os400 to true?

> eval: 001-0014 Command 
> /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin/java not found.

That's not a good sign, but it looks like some java executable was found.  What 
prints the above message with the odd prefix?

> java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
>

The above would indicate that setclasspath.sh failed.

One thing you didn't tell us was exactly how you start Tomcat.  Have you tried 
starting Tomcat from a command prompt so you can see the display of the derived 
variables, such as CLASSPATH?

 - Chuck


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


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



Re: Tomcat 6.0.35 -crossing maxThreads configured count

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

G,

On 1/23/12 8:44 AM, gnath wrote:
> Recently i happened to check our access logs when the server hung
> and stopped responding. We were printing the thread number in the
> logs and i have seen the number going upto 770 (though the max is 
> configured at 500). I was under impression that the threads will
> be shared among the connectors and max it can go to 500. Could you 
> please explain why im seeing very high number than configured? Is 
> that maxThreads value per connector?

Since you are using a thread pool, threads are probably expiring after
a certain period of time. New threads get numbers that increase
constantly over time, so you will see this number (in the name of the
thread) increase over maxThreads. It's nothing to worry about.

- -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/

iEYEARECAAYFAk8dtFAACgkQ9CaO5/Lv0PCdFwCdFF3NwnElEm6WaNAO7MOB3B5b
LIYAoL9dfu+mULYAlt0oSDgUoV0oFZ2R
=GkNd
-END PGP SIGNATURE-

-
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

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To whom it may concern,

On 1/23/12 1:21 PM, removeps-c...@yahoo.com wrote:
> Initially I thought that my RootJDBCRealm might be the problem,
> but how can that be? RootJDBCRealm extends Tomcat's own JDBCRealm.
> It overrides authenticate to call super.authenticate and if there
> are 3 failures (in that super.authenticate returns null), then it
> locks out the user. So could the user of RootJDBCRealm still be a
> problem?

It obviously depends upon what code is in RootJCBDRealm. Care you share?

As someone else already pointed out, you might want to look at
LockOutRealm.

- -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/

iEYEARECAAYFAk8duqYACgkQ9CaO5/Lv0PCkAwCfdhqhvv/WR81eJn/GtlZf2ary
wh8An17S8BA/zToMQjLYmHthGBtJRxJy
=LfEC
-END PGP SIGNATURE-

-
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

2012-01-23 Thread removeps-code
--- On Mon, 1/23/12, Daniel Mikusa  wrote:

> From: Daniel Mikusa 
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List" 
> Date: Monday, January 23, 2012, 10:55 AM
> On Mon, 2012-01-23 at 10:21 -0800, removeps-c...@yahoo.com
> wrote:
> > Initially I thought that my RootJDBCRealm might be the
> problem, but how can that be?  
> 
> > RootJDBCRealm extends Tomcat's own JDBCRealm.  It
> overrides authenticate to call super.authenticate and if
> there are 3 failures (in that super.authenticate returns
> null), then it locks out the user.
> 
> Sounds a lot like the LockOutRealm.
> 
>   https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#LockOutRealm

> 
> Any reason you opted not to use it?


Sorry, I did not know about this class.  Will this class work if you have many 
Tomcats on different machines (possibly load balancing) so regardless of which 
exact machine the user is directed to, lock realm will know the number of 
failed login attempts on other machines?



> 
> Dan
> 
> >   So could the user of RootJDBCRealm
> still be a problem?  Thanks.
> > 
> > --- On Mon, 1/23/12, Mark Thomas 
> wrote:
> > 
> > > From: Mark Thomas 
> > > Subject: Re: Connection.close() has already been
> called during login
> > > To: "Tomcat Users List" 
> > > Date: Monday, January 23, 2012, 12:49 AM
> > > 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
> > > > 
> > > > 
> > > > 
> > > >    > > className="pacific.tomcat.RootJDBCRealm"
> > > >         
> > > 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"/>
> > > > 
> > > >

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

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To whom it may concern,

On 1/23/12 2:54 PM, removeps-c...@yahoo.com wrote:
> Sorry, I did not know about [LockOutRealm].  Will this class work
> if you have many Tomcats on different machines (possibly load
> balancing) so regardless of which exact machine the user is
> directed to, lock realm will know the number of failed login
> attempts on other machines?

No, neither this nor any other Tomcat realms are cluster-aware.

If you want to track authentication failures across a cluster, you
could subclass LockOutRealm and override these methods:

- - isLocked
- - unlock
- - registerAuthFailure

This will allow you to handle the cluster-sync behavior separately
from the authentication behavior which this class already handles.

I'm interested in seeing what you come up with for communicating with
the rest of the cluster.

- -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/

iEYEARECAAYFAk8dv+4ACgkQ9CaO5/Lv0PDRnwCgvZFJvYXbU8Gwec6y430aD/rz
Kk4An2C5ZwXZf4NEaS31A5CWngqGxI9F
=zDyr
-END PGP SIGNATURE-

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



Re: parallel webapp initialization

2012-01-23 Thread David Rees
On Tue, Oct 11, 2011 at 6:42 AM, Mark Thomas  wrote:
> I have added a patch based on the previous patches that adds:
> - threaded start/stop for Contexts
> - threaded start/stop for Hosts
> - threaded deployment
>
> Control over the number of threads is via server.xml and/or JMX. This
> can be changed dynamically.
>
> Review, feedback, testing etc. welcome.
>
> With 4 threads rather than the current 1 (on a 8-core machine), I saw a
> 20-25% improvement in start time with a large number of Contexts that
> all start quickly. I'd expect to see better results in situations where
> 1 few Contexts start slowly but most are quick.

Resurrecting an old thread, but I've started using this in Tomcat
7.0.25 with good results - have a Tomcat instance used for testing
with a couple dozen contexts that take a while to load each, but with
startStopThreads bumped up it reduces startup time from 60 seconds to
20 seconds using all available CPU cores.  Very helpful!

Thanks!

-Dave

-
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

2012-01-23 Thread removeps-code
My code does not talk to another cluster as I have a single Tomcat only, but 
just wondering how one would scale.

Maybe the strategy to handle clusters is to write information, such as the list 
of the users to the number of times they have logged in in the last hour, into 
a location shared by all machines.  In my code below the code is stored in 
failedAttempts which is a Map where 
FailedAttempt represents the number of times the user has logged in in the last 
hour or whatever.  It is in-memory, which is fine for one Tomcat.

But we could move this Map into a file that is on a mounted drive available 
from all Tomcat machines, or we could store it in the database.  Either way we 
have to synchronize writes to the file or database, and I think database does 
this automatically, and maybe FileLock will do the job for the files.  But 
anyway, it sounds complicated.

As for my my authenticate it was as follows, although I don't see this should 
cause the failure in the subject of this email -- "Connection.close() has 
already been called during login":

   public Principal authenticate(String username, String credentials)
   {
  threadUserLockedOut.remove();
  long curTime = System.currentTimeMillis();
  FailedAttempt failedAttempt = failedAttempts.get(username);
  if (failedAttempt != null && 
failedAttempt.checkFailedAttemptsReached(curTime))
  {
 threadUserLockedOut.set(Boolean.TRUE);
 return null;
  }
  Principal result = super.authenticate(username, credentials);
  if (result == null)
  {
 if (failedAttempt != null)
 {
failedAttempt.incNumFailedAttempts();
if (failedAttempt.maxFailedAttemptsReached())
{
   failedAttempt.setFirstFailedTime(curTime);
   logger.warn("User '" + username + "' is locked out after " + 
MAX_FAILED_ATTEMPTS + " failed attempts");
   threadUserLockedOut.set(Boolean.TRUE);
   return null;
}
 }
 else
 {
failedAttempt = new FailedAttempt(curTime);
failedAttempts.put(username, failedAttempt);
 }
  }
  else
  {
 if (failedAttempt != null)
 {
failedAttempts.remove(username);
 }
  }
  return result;
   }


--- On Mon, 1/23/12, Christopher Schultz  wrote:

> From: Christopher Schultz 
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List" 
> Date: Monday, January 23, 2012, 12:15 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> To whom it may concern,
> 
> On 1/23/12 2:54 PM, removeps-c...@yahoo.com
> wrote:
> > Sorry, I did not know about [LockOutRealm].  Will
> this class work
> > if you have many Tomcats on different machines
> (possibly load
> > balancing) so regardless of which exact machine the
> user is
> > directed to, lock realm will know the number of failed
> login
> > attempts on other machines?
> 
> No, neither this nor any other Tomcat realms are
> cluster-aware.
> 
> If you want to track authentication failures across a
> cluster, you
> could subclass LockOutRealm and override these methods:
> 
> - - isLocked
> - - unlock
> - - registerAuthFailure
> 
> This will allow you to handle the cluster-sync behavior
> separately
> from the authentication behavior which this class already
> handles.
> 
> I'm interested in seeing what you come up with for
> communicating with
> the rest of the cluster.
> 
> - -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/
> 
> iEYEARECAAYFAk8dv+4ACgkQ9CaO5/Lv0PDRnwCgvZFJvYXbU8Gwec6y430aD/rz
> Kk4An2C5ZwXZf4NEaS31A5CWngqGxI9F
> =zDyr
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
>

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



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

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To whom it may concern,

On 1/23/12 4:20 PM, removeps-c...@yahoo.com wrote:
> My code does not talk to another cluster as I have a single Tomcat 
> only, but just wondering how one would scale.

Me too.

> Maybe the strategy to handle clusters is to write information, such
>  as the list of the users to the number of times they have logged
> in in the last hour, into a location shared by all machines.

That sounds fairly straightforward.

> In my code below the code is stored in failedAttempts which is a
> Map where FailedAttempt
> represents the number of times the user has logged in in the last
> hour or whatever. It is in-memory, which is fine for one Tomcat.

Right. This is how Tomcat does things in its own LockOutRealm. Take a
look at the code. It works with all realm types (see the code for the
different authenticate() methods it implements).

> But we could move this Map into a file that is on a mounted drive 
> available from all Tomcat machines, or we could store it in the 
> database. Either way we have to synchronize writes to the file or 
> database, and I think database does this automatically, and maybe 
> FileLock will do the job for the files. But anyway, it sounds
> complicated.

memcached. Cassandra. Whatever.

> As for my my authenticate it was as follows, although I don't see 
> this should cause the failure in the subject of this email -- 
> "Connection.close() has already been called during login":

Yup, it certainly doesn't look like your code does anything with the
superclass's Connection.

> public Principal authenticate(String username, String credentials) 
> { threadUserLockedOut.remove();

Why in the world are you using a ThreadLocal in here?

It makes me wonder what other odd things you are doing in your Realm
(or anywhere else for that matter).

- -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/

iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ
5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9
=Elm7
-END PGP SIGNATURE-

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



Re: Critical Problem Tomcat 7

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lau,

On 1/18/12 6:52 PM, Lau Eng Huat wrote:
> I have a strange problem. I have deleted a servlet from the project
> in netbeans but the uncompile source code still says the file
> exist.

I'll bite. What does "uncomple source code" mean.

Did you delete the .class file or the .java file or both?

> I have deleted the WEB-INF\classes and did a clean and build.
> Still the problems exists. Does anybody knows how to solved this
> problem ???

It's not really clear what the problem is.

If you think something is really out-of-sync, you should:

1. Stop Tomcat
2. Completely remove your WAR file or exploded WAR Directory
3. Completely remove your CATALINA_BASE/work directory and its
   contents
4. Re-build your webapp cleanly and re-deploy it
5. Start Tomcat

> Jan 19, 2012 7:46:37 AM org.apache.catalina.core.ApplicationContext
> log INFO: Marking servlet AdminCardServletLogin as unavailable Jan
> 19, 2012 7:46:37 AM org.apache.catalina.core.StandardWrapperValve
> invoke SEVERE: Allocate exception for servlet ServletABC 
> java.lang.RuntimeException: Uncompilable source code - 
> AllReadyDeletedServlet

If, after the above steps, you are still having problems, please post
your entire catalina.out file back with your next post.

- -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/

iEYEARECAAYFAk8d5CUACgkQ9CaO5/Lv0PAvLwCgw2ljN97KjA9XXiJLqdRukhag
1DIAnjTYUgxkFVcMF1QOJRM8XFEGjLjK
=OTs2
-END PGP SIGNATURE-

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



Re: Problem bringing up SSL with a CA certificate

2012-01-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James,

On 1/18/12 12:37 PM, James Lampert wrote:
> So far, I've had complete success using self-signed certificates,
> both here and on the customer box, once I found out that the CN
> needs to match the domain name.

;)

> But now, we're trying to get the customer box up on a CA-signed 
> certificate, and Tomcat doesn't like it. (Given that we haven't
> done it on our own box, it's kind of a case of the blind leading
> the blind.) We had our contact with the customer follow the
> procedure given on
> 
> http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Importing_the_Certificate
>
> 
> 
> and I put the resulting keystore into service, started Tomcat, and
> got this in logs/catalina.out:
> 
>> SEVERE: Failed to initialize end point associated with
>> ProtocolHandler ["http-bio-443"]  Throwable occurred:
>> java.io.IOException: Alias name tomcat does not identify a key
>> entry at

Did you also put your server's key into the keystore?

> If I list the keystore, I get:
>> Keystore type: jks
>>  Keystore provider: IBMJCE
>> 
>> 
>> Your keystore contains 2 entries
>> 
>> 
>> root, Jan 18, 2012, trustedCertEntry,
>> Certificate fingerprint (MD5):
>> D6:6A:92:1C:83:BF:A2:AE:6F:99:5B:44:E7:C2:AB:2A tomcat, Jan 18,
>> 2012, trustedCertEntry,
>> Certificate fingerprint (MD5):
>> 55:D7:4D:D4:83:01:D6:E0:EB:A4:F3:9A:06:BD:87:38

It looks like you only have certificates. Did you forget to import the
key into the keystore?

- -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/

iEYEARECAAYFAk8d5S0ACgkQ9CaO5/Lv0PC7oACdHek6Dxn2r0p2TXz7w9IxYJv8
EecAoI45tZqdrBsTZGII759VyURQAsFL
=beQr
-END PGP SIGNATURE-

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



Re: Problem bringing up SSL with a CA certificate

2012-01-23 Thread James Lampert

Christopher Schultz wrote:

Did you also put your server's key into the keystore?


It seems that when the customer rep jumped the gun and submitted a CSR 
to Thawte before we even had Tomcat running on a self-signed 
certificate, he did so using IBM DCM, whose keystores are incompatible 
with Keytool, and presumably also with Tomcat.


Fortunately, there's still a few days left to get a revocation and 
refund, and start from scratch the right way.


Don't you just love it when end-users jump the gun, and pay good money 
to a third party for things before you have the specs to give them?


--
JHHL

-
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

2012-01-23 Thread removeps-code


--- On Mon, 1/23/12, Christopher Schultz  wrote:

> From: Christopher Schultz 
> Subject: Re: Connection.close() has already been called during login
> To: "Tomcat Users List" 
> Date: Monday, January 23, 2012, 2:42 PM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> To whom it may concern,
> 
> On 1/23/12 4:20 PM, removeps-c...@yahoo.com
> wrote:
> > My code does not talk to another cluster as I have a
> single Tomcat 
> > only, but just wondering how one would scale.
> 
> Me too.
> 
> > Maybe the strategy to handle clusters is to write
> information, such
> >  as the list of the users to the number of times
> they have logged
> > in in the last hour, into a location shared by all
> machines.
> 
> That sounds fairly straightforward.
> 
> > In my code below the code is stored in failedAttempts
> which is a
> > Map where
> FailedAttempt
> > represents the number of times the user has logged in
> in the last
> > hour or whatever. It is in-memory, which is fine for
> one Tomcat.
> 
> Right. This is how Tomcat does things in its own
> LockOutRealm. Take a
> look at the code. It works with all realm types (see the
> code for the
> different authenticate() methods it implements).
> 
> > But we could move this Map into a file that is on a
> mounted drive 
> > available from all Tomcat machines, or we could store
> it in the 
> > database. Either way we have to synchronize writes to
> the file or 
> > database, and I think database does this
> automatically, and maybe 
> > FileLock will do the job for the files. But anyway, it
> sounds
> > complicated.
> 
> memcached. Cassandra. Whatever.
> 
> > As for my my authenticate it was as follows, although
> I don't see 
> > this should cause the failure in the subject of this
> email -- 
> > "Connection.close() has already been called during
> login":
> 
> Yup, it certainly doesn't look like your code does anything
> with the
> superclass's Connection.
> 
> > public Principal authenticate(String username, String
> credentials) 
> > { threadUserLockedOut.remove();
> 
> Why in the world are you using a ThreadLocal in here?

The use of the ThreadLocal is unrelated to the connection timing out.  It's 
just a variable to indicate that in this thread the user is locked out.  It is 
used later by my RootFormAuthenticator which extends FormAuthenticator to print 
out a message like "Your account has been locked out due to N failed attempts". 
 FYI

   @Override
   protected void forwardToErrorPage(Request request, HttpServletResponse 
response, LoginConfig loginConfig) throws IOException
   {
  ...
  if (realm.isThreadUserLockedOut())
  {
 message.append("Your account has been locked out due
 ...
  }
  else
  {
 message.append("Sorry, the username or password you supplied is 
invalid. Please try again.");
  }
  realm.clearThreadUserLockedOut();
  request.setAttribute("loginErrorMessage", message);
  super.forwardToErrorPage(request, response, loginConfig);
   }


The actual error page, which is a jsp page, has on it the following HTML




 
> It makes me wonder what other odd things you are doing in
> your Realm
> (or anywhere else for that matter).
> 
> - -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/
> 
> iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ
> 5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9
> =Elm7
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
>

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



Re: Critical Problem Tomcat 7

2012-01-23 Thread Brian Burch

On 24/01/12 08:50, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lau,

On 1/18/12 6:52 PM, Lau Eng Huat wrote:

I have a strange problem. I have deleted a servlet from the project
in netbeans but the uncompile source code still says the file
exist.


I'll bite. What does "uncomple source code" mean.

Did you delete the .class file or the .java file or both?


I have deleted the WEB-INF\classes and did a clean and build.
Still the problems exists. Does anybody knows how to solved this
problem ???


It's not really clear what the problem is.

If you think something is really out-of-sync, you should:

1. Stop Tomcat
2. Completely remove your WAR file or exploded WAR Directory
3. Completely remove your CATALINA_BASE/work directory and its
contents
4. Re-build your webapp cleanly and re-deploy it
5. Start Tomcat


If those very sensible five steps don't help, then...

6. It might be worth clearing the contents of the
~/.netbeans/x.x/cache/ directory, too. (You won't find the file in an 
obvious package hierarchy of directories - it is probably just lumped 
into one of the all-*.dat files). If you wipe out everything in cache, 
then stop netbeans, it will take a while to start while it repopulates 
the cache by compiling all your files again.


I don't know whether this will resolve your problem, but it wouldn't be 
the first time confusion was caused by something "supposedly deleted" 
under netbeans still hanging around.


Regards,

Brian


Jan 19, 2012 7:46:37 AM org.apache.catalina.core.ApplicationContext
log INFO: Marking servlet AdminCardServletLogin as unavailable Jan
19, 2012 7:46:37 AM org.apache.catalina.core.StandardWrapperValve
invoke SEVERE: Allocate exception for servlet ServletABC
java.lang.RuntimeException: Uncompilable source code -
AllReadyDeletedServlet


If, after the above steps, you are still having problems, please post
your entire catalina.out file back with your next post.

- -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/

iEYEARECAAYFAk8d5CUACgkQ9CaO5/Lv0PAvLwCgw2ljN97KjA9XXiJLqdRukhag
1DIAnjTYUgxkFVcMF1QOJRM8XFEGjLjK
=OTs2
-END PGP SIGNATURE-

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



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



Re: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)

2012-01-23 Thread James Lampert

Caldarale, Charles R wrote:

One thing you didn't tell us was exactly how you start Tomcat.  Have
you tried starting Tomcat from a command prompt so you can see the
display of the derived variables, such as CLASSPATH?


We start it from a variation of the OS/400 CL program given in this blog 
entry by "BetterThanZero": 
http://as400samplecode.blogspot.com/2011/06/install-tomcat-on-iseries-as400-tomcat.html


His CL program is:

PGM  
ADDENVVAR  ENVVAR(JAVA_HOME) +   
 VALUE('/QIBM/ProdData/Java400/jdk15')   
MONMSG MSGID(CPF)
SBMJOB CMD(QSH +  
 CMD('/apache/apache-tomcat-6.0.32/bin/start+
 up.sh')) JOB(CATALINA) JOBQ($jobqName) +
 CPYENVVAR(*YES) ALWMLTTHD(*YES)  


ours is adjusted to where we put Tomcat in the file system.

And up until a few minutes ago (hours after I first looked at your 
post), how to launch from a command line had not occurred to me (the 
answer, of course, would be to type the value of the CMD parameter on 
the "adjusted" version of the SBM job above (sometimes, even after 
almost eighteen years of working with the AS/400 platform, I surprise 
myself with how dense I can be!).


At any rate,


qsh CMD('/WINTOUCH/TOMCAT/BIN/STARTUP.SH')


produces:

/WINTOUCH/TOMCAT/BIN/catalina.sh: 001-0019 Error found searching for command 
tty. No such path or directory.  
Using CATALINA_BASE:   /wintouch/tomcat  
Using CATALINA_HOME:   /wintouch/tomcat  
Using CATALINA_TMPDIR: /wintouch/tomcat/temp 
Using JRE_HOME:/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
Using CLASSPATH:   /wintouch/tomcat/bin/bootstrap.jar:/wintouch/tomcat/bi
n/tomcat-juli.jar


at which point it sits there for under 2 seconds before terminating, 
leaving this in catalina.out:


java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina 
at java.net.URLClassLoader.findClass(URLClassLoader.java:432) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:642)  
at java.lang.ClassLoader.loadClass(ClassLoader.java:608)  
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236) 
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) 


By contrast, if I enter the same command on a command line on our V6 
box, I got the same, except for the initial "no such path or directory" 
exception, and then it sat there until I signed on from another terminal 
session and (after first verifying that the port had opened) terminating 
Tomcat.


--
JHHL

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



Unable to access images stored in webapps//WEB-INF/images ?

2012-01-23 Thread Alastair Baldwin
Dear Users

Why am I able to access images stored here:

http://localhost:8080/imageUploader/1234.jpg


but not here:

http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg


File permissions are the same

Any ideas?

Thanks

Alastair

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



Re: Unable to access images stored in webapps//WEB-INF/images ?

2012-01-23 Thread Igor Cicimov
On Tue, Jan 24, 2012 at 12:21 PM, Alastair Baldwin <
alastairgbald...@yahoo.co.uk> wrote:

> Dear Users
>
> Why am I able to access images stored here:
>
> http://localhost:8080/imageUploader/1234.jpg
>
>
> but not here:
>
> http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg
>
>
> File permissions are the same
>
> Any ideas?
>
> Thanks
>
> Alastair
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
catalina.policy file? Although I'm not clear why on earth would you like to
store images inside the application WEB-INF directory?


Re: Unable to access images stored in webapps//WEB-INF/images ?

2012-01-23 Thread removeps-code
Tomcat doesn't let you access anything in the META-INF or WEB-INF folders.  
These folders have config for your system, and may contain passwords (such as 
META-INF/context.xml which has passwords for the datasources).  Besides, people 
can get into WEB-INF/lib and WEB-INF/classes and web.xml and see your 
implementation details.

--- On Mon, 1/23/12, Alastair Baldwin  wrote:

> From: Alastair Baldwin 
> Subject: Unable to access images stored in webapps//WEB-INF/images ?
> To: "users@tomcat.apache.org" 
> Date: Monday, January 23, 2012, 5:21 PM
> Dear Users
> 
> Why am I able to access images stored here:
> 
> http://localhost:8080/imageUploader/1234.jpg
> 
> 
> but not here:
> 
> http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg
> 
> 
> File permissions are the same
> 
> Any ideas?
> 
> Thanks
> 
> Alastair
> 
> -
> 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: Unable to access images stored in webapps//WEB-INF/images ?

2012-01-23 Thread Caldarale, Charles R
> From: removeps-c...@yahoo.com [mailto:removeps-c...@yahoo.com] 
> Subject: Re: Unable to access images stored in webapps//WEB-INF/images 
> ?

> Tomcat doesn't let you access anything in the META-INF or WEB-INF folders.

It's not just Tomcat - the servlet spec forbids direct client access to 
anything in WEB-INF.

 - Chuck


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


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



Re: Restarting tomcat 7.0.23 on MAC OS X 10.6

2012-01-23 Thread Oliver Due Billing
Did a thread dump.. I have some locked threads and it just keeps going, any
smoking gun here?

Oliver-Billings-MacBook-Pro:bin ob$ sudo jstack -l 18866
2012-01-24 08:26:03
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02-402 mixed
mode):

"http-bio-80-exec-11" daemon prio=5 tid=10d0e2000 nid=0x116732000 waiting
on condition [116731000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <7f49d0798> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
- None

"Attach Listener" daemon prio=9 tid=101d5e800 nid=0x111fd9000 waiting on
condition []
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
- None

"GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=10d4df800
nid=0x1164ee000 waiting on condition [1164ed000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513)
at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
- None

"GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=103e06800
nid=0x129203000 waiting on condition [129202000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513)
at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
- None

"GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=103a7d800
nid=0x111a04000 waiting on condition [111a03000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513)
at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
- None

"http-bio-80-exec-10" daemon prio=5 tid=101b79800 nid=0x12a9aa000 waiting
on condition [12a9a9000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:126)
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
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.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
- locked <7f42a96f0> (a org.apache.tomcat.util.net.SocketWrapper)
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:680)

   Locked ownable synchronizers:
- <7f48c81a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

"http-bio-80-exec-9" daemon prio=5 tid=103fc5800 nid=0x12a66c000 waiting on
condition [12a66b000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <7f49d0798> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:

Re: parallel webapp initialization

2012-01-23 Thread Pid *
On 23 Jan 2012, at 21:12, David Rees  wrote:

> On Tue, Oct 11, 2011 at 6:42 AM, Mark Thomas  wrote:
>> I have added a patch based on the previous patches that adds:
>> - threaded start/stop for Contexts
>> - threaded start/stop for Hosts
>> - threaded deployment
>>
>> Control over the number of threads is via server.xml and/or JMX. This
>> can be changed dynamically.
>>
>> Review, feedback, testing etc. welcome.
>>
>> With 4 threads rather than the current 1 (on a 8-core machine), I saw a
>> 20-25% improvement in start time with a large number of Contexts that
>> all start quickly. I'd expect to see better results in situations where
>> 1 few Contexts start slowly but most are quick.
>
> Resurrecting an old thread, but I've started using this in Tomcat
> 7.0.25 with good results - have a Tomcat instance used for testing
> with a couple dozen contexts that take a while to load each, but with
> startStopThreads bumped up it reduces startup time from 60 seconds to
> 20 seconds using all available CPU cores.  Very helpful!

That's great - and thanks for letting us know.

If you have time, I think it would be interesting to know your
application sizes, individual startup time and how many
startStopThreads you are using.


p

>
> Thanks!
>
> -Dave
>
> -
> 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