date:20140404


On 4.4.2014 5:23, Toby Lazar wrote:

I've run my client program with the -Djavax.net.debug=all option. First it
listed out all of the trusted authorities. Mine is GoDaddy and this is the
record:



That one is not the issuer of your certificate.  GoDaddy has many issuing
certificates.  The GoDaddy certificate the client trusts expires in 2034
whereas your issuer certificates expire in 2031/2037.  Also, the DNs are
different.  Better to identify the trusted certificate by serial number and
subject key identifier.


+1.

It seems to be known issue with GoDaddy G2 certificate:

http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called 
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA 
signs all their SHA-2 certificates. This is where the problem lies - 
GoDaddy has not added their newer G2 CA server to the default java 
truststore - causing default java installations to not trust it's 
authority, and hence, does not trust your chained certificate. The 
work-around until GoDaddy adds the G2 CA server to the default 
truststore is to simply rekey your cert using SHA-1 as-to get a cert 
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers 
until your cert expires (obviously).


FTR, GoDaddy or any other CA can't just add certificate to Java root 
certificates, but it must apply at Oracle for inclusion.




This is what I think is the relevant part:
[3]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
   CA:false
   PathLen:2147483647
]


It just says that server certificate you have cannot be used to sign 
other certificates, nothing else. That is irrelevant for you.



-Ognjen

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

Re: Catalina start problem

2014-04-04 Thread Utkarsh Dave

I once received similar exception while starting tomcat, but i was trying
to modify the web.xml with incorrect tags.
Try to get the thread dumps and track the changes that were performed
before your attempt to start tomcat.


On Wed, Apr 2, 2014 at 1:53 PM, Neeraj Sinha neerajsinha@gmail.comwrote:

 I am trying to start tomcat on linux and I am getting LifecycleException
 exception whose snippet is below:

 Apr 2, 2014 8:33:53 AM org.apache.catalina.core.AprLifecycleListener init
 INFO: The APR based Apache Tomcat Native library which allows optimal
 performance in production environments was not found on the
 java.library.path:

 /usr/java/jdk1.6.0_38/jre/lib/amd64/server:/usr/java/jdk1.6.0_38/jre/lib/amd64:/usr/java/jdk1.6.0_38/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
 Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init
 INFO: Initializing ProtocolHandler [http-bio-8080]
 Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init
 INFO: Initializing ProtocolHandler [ajp-bio-8009]
 Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina load
 INFO: Initialization processed in 890 ms
 Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start
 SEVERE: Catalina.start:
 org.apache.catalina.LifecycleException: Failed to start component
 [StandardServer[8005]]
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:684)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at

 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
 Caused by: java.lang.NoSuchMethodError:
 org.apache.naming.NamingContext.setExceptionOnFailedWrite(Z)V
 at

 org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:264)
 at

 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at

 org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
 at

 org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:724)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 ... 7 more
 Apr 2, 2014 8:33:53 AM org.apache.catalina.startup.Catalina start
 INFO: Server startup in 6 ms

 One reason I could guess for this is that Tomcat jar may not be proper but
 I have checked that and that looks fine to me.

 Appreciated if somebody could help me.

Re: Valid certificate chain failing with unable to find valid certification path to requested

2014-04-04 Thread jeffery.scott.crump

Ognjen,


You were correct. The GoDaddy  GA2 certificate was not in the root 
distributions. I re-keyed it to GA1 and that fixed the problems.


Thank you all.

Jeff Crump






Sent from Windows Mail





From: Ognjen Blagojevic
Sent: ‎Friday‎, ‎April‎ ‎4‎, ‎2014 ‎3‎:‎14‎ ‎AM
To: Tomcat Users List





On 4.4.2014 5:23, Toby Lazar wrote:
 I've run my client program with the -Djavax.net.debug=all option. First it
 listed out all of the trusted authorities. Mine is GoDaddy and this is the
 record:


 That one is not the issuer of your certificate.  GoDaddy has many issuing
 certificates.  The GoDaddy certificate the client trusts expires in 2034
 whereas your issuer certificates expire in 2031/2037.  Also, the DNs are
 different.  Better to identify the trusted certificate by serial number and
 subject key identifier.

+1.

It seems to be known issue with GoDaddy G2 certificate:

http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called 
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA 
signs all their SHA-2 certificates. This is where the problem lies - 
GoDaddy has not added their newer G2 CA server to the default java 
truststore - causing default java installations to not trust it's 
authority, and hence, does not trust your chained certificate. The 
work-around until GoDaddy adds the G2 CA server to the default 
truststore is to simply rekey your cert using SHA-1 as-to get a cert 
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers 
until your cert expires (obviously).

FTR, GoDaddy or any other CA can't just add certificate to Java root 
certificates, but it must apply at Oracle for inclusion.


 This is what I think is the relevant part:
 [3]: ObjectId: 2.5.29.19 Criticality=true
 BasicConstraints:[
CA:false
PathLen:2147483647
 ]

It just says that server certificate you have cannot be used to sign 
other certificates, nothing else. That is irrelevant for you.


-Ognjen

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

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

On Apr 4, 2014, at 1:19 AM, Saurabh Saraswat ssaras...@pivotalindia.com wrote:

 Dear All,
 
 I am doing connection pooling with tomcat 7.0.39 and MySQL 5.5.After
 searching on google and with your help i have done the below things.
 Even i am able to get the connection successfully using this but getting
 some trouble and exception.
 I am explaining you all steps done by me-
 
 *1. Have created a context.xml*
 
 I have put this context.xml in the META-INF folder of my application. but
 when i am deploying the web app to the server then it is not creating its
 copy to ${CATALINA-BASE}/conf/Catalina/locathost. Why is that so ?

There are a couple possibilities.

1.) Look at “deployXML” attribute of your Host tag.  If this is set to false, 
it will disable parsing the context XML descriptor embedded inside the 
application.  This defaults to true, unless you are running with a security 
manager, then it defaults to false.

   
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation

2.) Look at the “copyXML attribute of both your Host and Context tags.  
This needs to be set to true, because the default in Tomcat 7 is false.

   
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation
   
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Standard_Implementation

If both attributes are set properly, you should see the META-INF/context.xml 
file from your application copied to “$CATALINA_BASE/conf/Catalina/localhost”.  

 
 But when i am putting this context.xml in ${CATALINA-BASE}/conf folder then
 its working.
 
 ?xml version=1.0 encoding=UTF-8?
 
 
 Context
  Resource name=jdbc/MaxDB auth=Container type=javax.sql.DataSource
   maxActive=100 maxIdle=30 maxWait=-1
   username=root password=root
 driverClassName=com.mysql.jdbc.Driver
 
 url=jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull/
 
 /Context
 
 *2. Mapping in web.xml*
 
 resource-ref
 descriptionMySql DataSource/description
 res-ref-namejdbc/MaxDB/res-ref-name
 res-typejavax.sql.DataSource/res-type
 res-authContainer/res-auth
 /resource-ref
 
 *3. Then on my servlet i am getting the object of connection like this-*
 
private static InitialContext ic;
protected static DataSource datasource;
private static Context ctx;
 
 public void doSomeStuff() throws DatabaseException
 {
   Connection conn = null;
   try
   {
  conn= getConnection();
 
  .
 // do the required stuff
 
   }
   catch (Exception ex)
{
 
}
finally
{
  conn.close();
}
 
 }
 
 *4. This is the method in my DAO Class i am using this method to get the
 object of connection at all of my servlet.*
 
   protected static Connection getConnection() throws DatabaseException
 {
Connection conn = null;
try
{
ctx = new InitialContext();
datasource = (DataSource)
 ctx.lookup(java:/comp/env/jdbc/MaxDB);
conn = datasource.getConnection();
}
catch (Exception ex)
{
 
}
return conn;
}
 
 Using all this i am able to get connection. But if number of hits increases
 to the server and Initially i got the the below exception-
 
 *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
 pool error Timeout waiting for idle object*

This means it was unable to get a connection from the pool within “maxWait” ms. 
 There are a few reasons this could happen, but I’d guess it’s because of the 
next error that you reported.

 
 Then i got the exception-
 
 *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create
 PoolableConnectionFactory (Access denied for user 'root'@'localhost' (using
 password: YES))*

Seems like you can’t connect to the database.  Have you double checked your 
user / password / host configuration info?

Dan

 
 Please assist me to know the root cause of the problem. I have searched it
 on google and have read lots of forum but did not get the satisfactory
 answer.
 
 Hope that you all are expert and your suggestion will be valuable for me.
 
 Thanking You!
 
 *Best Regards,*
 
 *Saurabh Sarasvat*


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

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

2014-04-04 Thread Saurabh Saraswat

Dear Dan,

Thanks for your response!

I have cross checked the user / password configuration. All is correct. As
i mentioned that initially i am getting the object of connection but after
some time (After few hits to database from application) my web app goes to
slow and than it stops working i i got the below exception-
*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
pool error Timeout waiting for idle object*

I searched for this and find that reason is maxWait ms then i set it to
-1 i think which tends to unlimited time. Still i am facing the same
problem.

Can you please let me know what others reason can cause this exception.


*Best Regards,*

*Saurabh Sarasvat*




On Fri, Apr 4, 2014 at 5:16 PM, Daniel Mikusa dmik...@gopivotal.com wrote:

 On Apr 4, 2014, at 1:19 AM, Saurabh Saraswat ssaras...@pivotalindia.com
 wrote:

  Dear All,
 
  I am doing connection pooling with tomcat 7.0.39 and MySQL 5.5.After
  searching on google and with your help i have done the below things.
  Even i am able to get the connection successfully using this but getting
  some trouble and exception.
  I am explaining you all steps done by me-
 
  *1. Have created a context.xml*
 
  I have put this context.xml in the META-INF folder of my application. but
  when i am deploying the web app to the server then it is not creating its
  copy to ${CATALINA-BASE}/conf/Catalina/locathost. Why is that so ?

 There are a couple possibilities.

 1.) Look at deployXML attribute of your Host tag.  If this is set to
 false, it will disable parsing the context XML descriptor embedded inside
 the application.  This defaults to true, unless you are running with a
 security manager, then it defaults to false.


 http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation

 2.) Look at the copyXML attribute of both your Host and Context
 tags.  This needs to be set to true, because the default in Tomcat 7 is
 false.


 http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation

 http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Standard_Implementation

 If both attributes are set properly, you should see the
 META-INF/context.xml file from your application copied to
 $CATALINA_BASE/conf/Catalina/localhost.

 
  But when i am putting this context.xml in ${CATALINA-BASE}/conf folder
 then
  its working.
 
  ?xml version=1.0 encoding=UTF-8?
 
 
  Context
   Resource name=jdbc/MaxDB auth=Container type=javax.sql.DataSource
maxActive=100 maxIdle=30 maxWait=-1
username=root password=root
  driverClassName=com.mysql.jdbc.Driver
 
 
 url=jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull/
 
  /Context
 
  *2. Mapping in web.xml*
 
  resource-ref
  descriptionMySql DataSource/description
  res-ref-namejdbc/MaxDB/res-ref-name
  res-typejavax.sql.DataSource/res-type
  res-authContainer/res-auth
  /resource-ref
 
  *3. Then on my servlet i am getting the object of connection like this-*
 
 private static InitialContext ic;
 protected static DataSource datasource;
 private static Context ctx;
 
  public void doSomeStuff() throws DatabaseException
  {
Connection conn = null;
try
{
   conn= getConnection();
 
   .
  // do the required stuff
 
}
catch (Exception ex)
 {
 
 }
 finally
 {
   conn.close();
 }
 
  }
 
  *4. This is the method in my DAO Class i am using this method to get the
  object of connection at all of my servlet.*
 
protected static Connection getConnection() throws DatabaseException
  {
 Connection conn = null;
 try
 {
 ctx = new InitialContext();
 datasource = (DataSource)
  ctx.lookup(java:/comp/env/jdbc/MaxDB);
 conn = datasource.getConnection();
 }
 catch (Exception ex)
 {
 
 }
 return conn;
 }
 
  Using all this i am able to get connection. But if number of hits
 increases
  to the server and Initially i got the the below exception-
 
  *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
  pool error Timeout waiting for idle object*

 This means it was unable to get a connection from the pool within
 maxWait ms.  There are a few reasons this could happen, but I'd guess
 it's because of the next error that you reported.

 
  Then i got the exception-
 
  *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create
  PoolableConnectionFactory (Access denied for user 'root'@'localhost'
 (using
  password: YES))*

 Seems like you can't connect to the database.  Have you double checked
 your user / password / host configuration info?

 Dan

 
  Please assist me to know the root cause of the problem. I have searched
 it
  on google and have read lots of forum but did not get the satisfactory
  answer.
 
  Hope that you all

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

2014-04-04 Thread David kerber


On 4/4/2014 8:22 AM, Saurabh Saraswat wrote:

Dear Dan,

Thanks for your response!

I have cross checked the user / password configuration. All is correct. As
i mentioned that initially i am getting the object of connection but after
some time (After few hits to database from application) my web app goes to
slow and than it stops working i i got the below exception-
*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
pool error Timeout waiting for idle object*

I searched for this and find that reason is maxWait ms then i set it to
-1 i think which tends to unlimited time. Still i am facing the same
problem.

Can you please let me know what others reason can cause this exception.


Sounds to me like you're either leaking connection objects and 
eventually run out of available connections in the pool, or your queries 
are taking so long that you run out of connections before you get any of 
them back.







*Best Regards,*

*Saurabh Sarasvat*




On Fri, Apr 4, 2014 at 5:16 PM, Daniel Mikusa dmik...@gopivotal.com wrote:


On Apr 4, 2014, at 1:19 AM, Saurabh Saraswat ssaras...@pivotalindia.com
wrote:


Dear All,

I am doing connection pooling with tomcat 7.0.39 and MySQL 5.5.After
searching on google and with your help i have done the below things.
Even i am able to get the connection successfully using this but getting
some trouble and exception.
I am explaining you all steps done by me-

*1. Have created a context.xml*

I have put this context.xml in the META-INF folder of my application. but
when i am deploying the web app to the server then it is not creating its
copy to ${CATALINA-BASE}/conf/Catalina/locathost. Why is that so ?


There are a couple possibilities.

1.) Look at deployXML attribute of your Host tag.  If this is set to
false, it will disable parsing the context XML descriptor embedded inside
the application.  This defaults to true, unless you are running with a
security manager, then it defaults to false.


http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation

2.) Look at the copyXML attribute of both your Host and Context
tags.  This needs to be set to true, because the default in Tomcat 7 is
false.


http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Standard_Implementation

If both attributes are set properly, you should see the
META-INF/context.xml file from your application copied to
$CATALINA_BASE/conf/Catalina/localhost.



But when i am putting this context.xml in ${CATALINA-BASE}/conf folder

then

its working.

?xml version=1.0 encoding=UTF-8?


Context
  Resource name=jdbc/MaxDB auth=Container type=javax.sql.DataSource
   maxActive=100 maxIdle=30 maxWait=-1
   username=root password=root
driverClassName=com.mysql.jdbc.Driver



url=jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull/


/Context

*2. Mapping in web.xml*

resource-ref
descriptionMySql DataSource/description
res-ref-namejdbc/MaxDB/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref

*3. Then on my servlet i am getting the object of connection like this-*

private static InitialContext ic;
protected static DataSource datasource;
private static Context ctx;

public void doSomeStuff() throws DatabaseException
{
   Connection conn = null;
   try
   {
  conn= getConnection();

  .
 // do the required stuff

   }
   catch (Exception ex)
{

}
finally
{
  conn.close();
}

}

*4. This is the method in my DAO Class i am using this method to get the
object of connection at all of my servlet.*

   protected static Connection getConnection() throws DatabaseException
{
Connection conn = null;
try
{
ctx = new InitialContext();
datasource = (DataSource)
ctx.lookup(java:/comp/env/jdbc/MaxDB);
conn = datasource.getConnection();
}
catch (Exception ex)
{

}
return conn;
}

Using all this i am able to get connection. But if number of hits

increases

to the server and Initially i got the the below exception-

*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
pool error Timeout waiting for idle object*


This means it was unable to get a connection from the pool within
maxWait ms.  There are a few reasons this could happen, but I'd guess
it's because of the next error that you reported.



Then i got the exception-

*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create
PoolableConnectionFactory (Access denied for user 'root'@'localhost'

(using

password: YES))*


Seems like you can't connect to the database.  Have you double checked
your user / password / host configuration info?

Dan



Please assist me to know the root cause of the

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

On Apr 4, 2014, at 8:22 AM, Saurabh Saraswat ssaras...@pivotalindia.com wrote:

 Dear Dan,
 
 Thanks for your response!
 
 I have cross checked the user / password configuration. All is correct.

If you’re getting “Access Denied” exceptions, there is only one cause and 
that’s bad credentials (or host + credentials, because MySQL can limit access 
based on the host).  If you’re not seeing these any more then, disregard.

 As i mentioned that initially i am getting the object of connection but after
 some time (After few hits to database from application) my web app goes to
 slow and than it stops working i i got the below exception-
 *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection,
 pool error Timeout waiting for idle object*

+1 to David’s suggestion.  You could be leaking connections or your queries are 
very slow.  

Two suggestions:

1.) Enable the slow query log on your MySQL server and see if the queries are 
slow.  Alternatively, login to your MySQL server and run ‘show processlist”.  
That will show you what queries are running.

2.) Enable DBCP’s abandoned connection detection.  See the “removeAbandoned” 
attribute.

  http://commons.apache.org/proper/commons-dbcp/configuration.html

With this (and logAbandoned), the pool will alert you when your application 
does not properly return connections to the pool.

Dan

 
 I searched for this and find that reason is maxWait ms then i set it to
 -1 i think which tends to unlimited time. Still i am facing the same
 problem.
 
 Can you please let me know what others reason can cause this exception.
 
 
 *Best Regards,*
 
 *Saurabh Sarasvat*
 
 
 
 
 On Fri, Apr 4, 2014 at 5:16 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 
 On Apr 4, 2014, at 1:19 AM, Saurabh Saraswat ssaras...@pivotalindia.com
 wrote:
 
 Dear All,
 
 I am doing connection pooling with tomcat 7.0.39 and MySQL 5.5.After
 searching on google and with your help i have done the below things.
 Even i am able to get the connection successfully using this but getting
 some trouble and exception.
 I am explaining you all steps done by me-
 
 *1. Have created a context.xml*
 
 I have put this context.xml in the META-INF folder of my application. but
 when i am deploying the web app to the server then it is not creating its
 copy to ${CATALINA-BASE}/conf/Catalina/locathost. Why is that so ?
 
 There are a couple possibilities.
 
 1.) Look at deployXML attribute of your Host tag.  If this is set to
 false, it will disable parsing the context XML descriptor embedded inside
 the application.  This defaults to true, unless you are running with a
 security manager, then it defaults to false.
 
 
 http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation
 
 2.) Look at the copyXML attribute of both your Host and Context
 tags.  This needs to be set to true, because the default in Tomcat 7 is
 false.
 
 
 http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Standard_Implementation
 
 http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Standard_Implementation
 
 If both attributes are set properly, you should see the
 META-INF/context.xml file from your application copied to
 $CATALINA_BASE/conf/Catalina/localhost.
 
 
 But when i am putting this context.xml in ${CATALINA-BASE}/conf folder
 then
 its working.
 
 ?xml version=1.0 encoding=UTF-8?
 
 
 Context
 Resource name=jdbc/MaxDB auth=Container type=javax.sql.DataSource
  maxActive=100 maxIdle=30 maxWait=-1
  username=root password=root
 driverClassName=com.mysql.jdbc.Driver
 
 
 url=jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull/
 
 /Context
 
 *2. Mapping in web.xml*
 
 resource-ref
 descriptionMySql DataSource/description
 res-ref-namejdbc/MaxDB/res-ref-name
 res-typejavax.sql.DataSource/res-type
 res-authContainer/res-auth
 /resource-ref
 
 *3. Then on my servlet i am getting the object of connection like this-*
 
   private static InitialContext ic;
   protected static DataSource datasource;
   private static Context ctx;
 
 public void doSomeStuff() throws DatabaseException
 {
  Connection conn = null;
  try
  {
 conn= getConnection();
 
 .
// do the required stuff
 
  }
  catch (Exception ex)
   {
 
   }
   finally
   {
 conn.close();
   }
 
 }
 
 *4. This is the method in my DAO Class i am using this method to get the
 object of connection at all of my servlet.*
 
  protected static Connection getConnection() throws DatabaseException
 {
   Connection conn = null;
   try
   {
   ctx = new InitialContext();
   datasource = (DataSource)
 ctx.lookup(java:/comp/env/jdbc/MaxDB);
   conn = datasource.getConnection();
   }
   catch (Exception ex)
   {
 
   }
   return conn;
   }
 
 Using all this i am able to get connection. But if number of hits
 increases
 to the server and

RE: SQLNestedException in Connection Pooling With Tomcat 7.0.39

2014-04-04 Thread Propes, Barry L

-Original Message-
From: Saurabh Saraswat [mailto:ssaras...@pivotalindia.com] 
Sent: Friday, April 04, 2014 7:23 AM
To: Tomcat Users List
Subject: Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

Dear Dan,

Thanks for your response!

I have cross checked the user / password configuration. All is correct. As i 
mentioned that initially i am getting the object of connection but after some 
time (After few hits to database from application) my web app goes to slow and 
than it stops working i i got the below exception-
*org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection, pool 
error Timeout waiting for idle object*

I searched for this and find that reason is maxWait ms then i set it to
-1 i think which tends to unlimited time. Still i am facing the same problem.

Can you please let me know what others reason can cause this exception.

*Best Regards,*

*Saurabh Sarasvat*

---

FWIW, I also have these attributes in my context.xml file, below or in addition 
to what you have, Saurabh.

maxIdle=30
maxWait=1
maxActive=10
testOnBorrow=true
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=28800
poolPreparedStatements=true
removeAbandoned=true
removeAbandonedTimeout=300
logAbandoned=false/

 -
 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: Valid certificate chain failing with unable to find valid certification path to requested

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ognjen,

On 4/4/14, 4:14 AM, Ognjen Blagojevic wrote:
 On 4.4.2014 5:23, Toby Lazar wrote:
 I've run my client program with the -Djavax.net.debug=all
 option. First it listed out all of the trusted authorities.
 Mine is GoDaddy and this is the record:
 
 
 That one is not the issuer of your certificate.  GoDaddy has many
 issuing certificates.  The GoDaddy certificate the client trusts
 expires in 2034 whereas your issuer certificates expire in
 2031/2037.  Also, the DNs are different.  Better to identify the
 trusted certificate by serial number and subject key identifier.
 
 +1.
 
 It seems to be known issue with GoDaddy G2 certificate:
 
 http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

 
 
 [GoDaddy] have 2 CA servers, one called Class 2 CA and the other
 called G2 CA. Their Class 2 CA signs all SHA-1 certificates, while
 the G2 CA signs all their SHA-2 certificates. This is where the
 problem lies - GoDaddy has not added their newer G2 CA server to
 the default java truststore - causing default java installations to
 not trust it's authority, and hence, does not trust your chained
 certificate. The work-around until GoDaddy adds the G2 CA server to
 the default truststore is to simply rekey your cert using SHA-1
 as-to get a cert signed by the Class 2 CA server. Rekeying is free
 for GoDaddy customers until your cert expires (obviously).

So they don't have a big Daddy certificate that has signed all of
their intermediate certificates? Boo. That would fix nearly everything.

 FTR, GoDaddy or any other CA can't just add certificate to Java
 root certificates, but it must apply at Oracle for inclusion.

If the problem is that the client trusts GoDaddy's ROOT certificate
and the server's certificate was signed by GoDaddy's intermediate
certificate (which should have been in turn signed by the ROOT
certificate), then the solution is to include the intermediate
certificate (or certificates... some CAs have longer chains) in your
keystore and configure Tomcat to serve both the server's cert and the
intermediate cert.

 This is what I think is the relevant part: [3]: ObjectId:
 2.5.29.19 Criticality=true BasicConstraints:[ CA:false 
 PathLen:2147483647 ]
 
 It just says that server certificate you have cannot be used to
 sign other certificates, nothing else. That is irrelevant for you.

Depending upon where this came from (there was no context given), you
are correct. If this is information from the GoDaddy certificate, then
it's likely an intermediate certificate and not a root cert.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPsFMAAoJEBzwKT+lPKRYrCkQALBDQmaPZfjy1bAwBGC36Yg9
fIqCeI37izMwCgaiGGSNw9mA6GUyJoEixzXorlD6kje/oroJveq/AEaBMZO6eWJ7
OSVqUbcFNFNF+waVSskIDU0+4eLZHYvAU5t8jAJpVy6Jenw0QHrYV3rt2OpE1w8w
w+sFg7FvqYth4oHVsSmrnBP1ncA90Bpsv49AXlQUhKQ5ielGKfJVcciBNhNRbZiF
atNQxcR+Xm++2mDJIx4l0sfS+XzEVY655QBpys02H051lfg1VeOMLroFtTdckhQZ
ECsIGPs2Ue69T4wjByY+pPeQ9HW77kKurVgV6pUbZaGTdLNV0gQqHNBVj5hNdriN
wNMZFFSWywnzX/UP+N1bbAfXm2Y4i8n7UQyQWIa+tY/74PzvUrIgZfYsxMeVM5Rz
erZvyIQaVBN4zdPgL9nHQNb4bMza42apNrwWeOrZDLPwv23EOD0E4tO/nkg95+7W
fobXN4+hQoK7s7PqKdkdIafwsnu7Kv1MFR+UatZ6evayOrE8k9MbQDQXYRZ1/5/N
DOavfNOOe73+AeJDXcaDNprGjWvzCEUCXfCPv7b76j9pd+o4zm+LGYQLNYcrE8lJ
uqXfgvijaRlDueNId7Qz+9wgkaZnUVtc/plyK47/4NjQ0RNgYWKvo2CAtvbBHR/u
qrEmBVjQuLKEek1TDRiw
=5CiA
-END PGP SIGNATURE-

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

Re: mod_jk - Failover behaviour and load + patch

2014-04-04 Thread Frederik Nosi


Hi Konstantin,

On 04/02/2014 12:01 PM, Konstantin Kolinko wrote:

2014-04-02 5:21 GMT+04:00 Frederik Nosi frederik.n...@postecom.it:

On 04/02/2014 12:21 AM, Christopher Schultz wrote:

On 3/26/14, 9:32 PM, Frederik Nosi wrote:

My scenario is Apache httpd + mod_jk + N Tomcat's in. The default
behaviour of load balanced workers in mod_jk in my testing is that
when a client requests a page (GET / POST / Whatever), the LB
worker tries the request to every ajp worker. This in contrast with
what i read here:


http://people.apache.org/~mturk/docs/article/ftwai.html
http://people.apache.org/%7Emturk/docs/article/ftwai.html

Expecially this part:


When having multiple nodes in a cluster you can improve your
application availability by implementing failover. The failover
means that if the particular elected node can not fulfill the
request the another node will be selected automatically. In case of
three nodes you are actually doubling your application
availability. The application response time will be slower during
failover, but none of your users will be rejected. Inside the
mod_jk configuration there is a special configuration parameter
called worker.retries that has default value of 3, but that needs
to be adjusted to the actual number of nodes in the cluster.

... worker.list=lbworker worker.lbworker.type=lb # Adjust to the
number of workers worker.retries=4
worker.lbworker.balance_workers=node1,node2,node3,node4 If you add
more then three workers to the load balancer adjust the retries
parameter to reflect that number. It will ensure that even in the
worse case scenario the request gets served if there is a single
operable node.

  From that it seems that the retries parameter in a load balancer
worker context should mean the number of real (AJP) workers to
try. (what i need indeed) but in my testing, that LB worker
parameter is the number of times that all the AJP workers that are
part of the LB worker get a round retry. In eg, having a LB worker
with 4 AJP workers, setting LB Worker's retries = 2, the behaviour
i see is that the AJP workers get called this way:

AJP1 - timeout [...] AJP4 - timeout

=== repeat again (retries == 2)

AJP1 - timeout [...] AJP4 - timeout

-- LB sends an error to the client.



Now from the online documentation the meaning of that parameter in
a load balancer worker context is'nt that clear, but from the link
i provided seems it was exactly what i needed, not the number of
retries to all AJP workers, but the number of single AJP workers to
try..

If that is not correct i can fill a bug report. If instead it's by
design, the attached patch adds a new parameter, lb_retries, that
does what i need. Of course it's a bit rough, but works.

Any comments? Am I getting stuff wrong?

I'm bumping this because I can see Rainer has fixed a bunch of things
in mod_jk over the last few days. Perhaps he's getting ready to do a
release or something.


Thanks Christopher, BTW on this issue I'm not even sure it's a documentation
bug, a bug in mod_jk or an unfullfilled expectation of mine :-)
Thing is, i had to use this cure.

I'm sure my patch is a bit faulty, the HTTP status codes returned are  500,
but i'm not sure they are in line with the protocol (503 / 504). but for now
it works for me though.


1. If you really want to submit a patch,  please attach it to an issue
in Bugzilla, so that it is not forgotten.


Okay, i will,


http://tomcat.apache.org/bugreport.html

2. You were lucky that you attachment has reached the list.  Usually
attachments are just removed by mailing list server.


Ok, sorry for that, i put that as attachment for avoiding word wrapping 
problems with my

mail client.



3. I cannot comment on the essence,  just two formal nits
1) The following line has a tab character instead of whitespaces:
+jk_log(l, JK_LOG_DEBUG, attempt %d, max attempts %d,


Ok, willl fix, thanks for pointing this.



2) An unneeded comment
+/* fredi - default */


Yep, leftover from my testing



3) Documentation =?
(xdocs/reference/workers.xml)


Ok, will do,




Noticed there were changes in mod_jk's git repo, i'm following it.


It is good that it works for you.
The official repository is subversion one.


Yes, noticed that, but as i'm not always inline i tend to use git. But 
svn is fine too


(Patches against the git repository are OK.  Maybe you want to submit
those .gitignore files, as a separate issue?)


Okay, will separate that part in case it turns useful.

Anyway, i know the patch i sent was rough, but i prefered to send it 
anyway to have

something concrete to explain what i wanted to do.



Best regards,
Konstantin Kolinko


Thanks Konstantin for your attention!


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




Frederik

-
To unsubscribe, e-mail:

Re: Catalina start problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neeraj,

On 4/4/14, 3:46 AM, Neeraj Sinha wrote:
 On 3 April 2014 23:06, Christopher Schultz
 ch...@christopherschultz.netwrote:
 
 Neeraj,
 
 On 4/2/14, 4:23 AM, Neeraj Sinha wrote:
 I am trying to start tomcat on linux and I am getting 
 LifecycleException exception whose snippet is below:
 
 Apr 2, 2014 8:33:53 AM 
 org.apache.catalina.core.AprLifecycleListener init INFO: The
 APR based Apache Tomcat Native library which allows optimal
 performance in production environments was not found on the
 java.library.path:
 
 /usr/java/jdk1.6.0_38/jre/lib/amd64/server:/usr/java/jdk1.6.0_38/jre/lib/amd64:/usr/java/jdk1.6.0_38/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib



 
Apr 2, 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init
 INFO: Initializing ProtocolHandler [http-bio-8080] Apr 2,
 2014 8:33:53 AM org.apache.coyote.AbstractProtocol init
 INFO: Initializing ProtocolHandler [ajp-bio-8009] Apr 2,
 2014 8:33:53 AM org.apache.catalina.startup.Catalina load
 INFO: Initialization processed in 890 ms Apr 2, 2014 8:33:53
 AM org.apache.catalina.startup.Catalina start SEVERE:
 Catalina.start: org.apache.catalina.LifecycleException:
 Failed to start component [StandardServer[8005]] at 
 org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)



 
at org.apache.catalina.startup.Catalina.start(Catalina.java:684)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method) at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)



 
at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)



 
at java.lang.reflect.Method.invoke(Method.java:597)
 at
 org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)

 
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
 Caused by: java.lang.NoSuchMethodError: 
 org.apache.naming.NamingContext.setExceptionOnFailedWrite(Z)V
 at
 
 org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:264)



 
at
 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)



 
at
 
 org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)



 
at
 
 org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:724)



 
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
 ... 7 more Apr 2, 2014 8:33:53 AM 
 org.apache.catalina.startup.Catalina start INFO: Server
 startup in 6 ms
 
 One reason I could guess for this is that Tomcat jar may not
 be proper but I have checked that and that looks fine to me.
 
 Appreciated if somebody could help me.
 
 What version of Tomcat are you trying to run? Have you modified
 your Tomcat installation other than changes to server.xml and
 adding web applications to it? Do any of your web applications
 have any Tomcat JAR files in them?
 
 Thanks. I am using version 7.0.34. I have not modified anything in
 tomcat installation but I have added JBoss client jars in
 /tomcat/lib   which is required for web apps to access EJB
 services.

This is almost certainly the problem. Which JARs did you add?

 Actually, I have this tomcat installed and running in few other
 environments also without any problem. I am trying to setup this on
 a new system where I copied the complete tomcat and apache files
 from one of the environment and modified their configuration files
 for domain and host configuration. Apart from this no other
 changes.

You really shouldn't mix libraries from other containers into Tomcat's
lib/ directory. JBoss uses Tomcat internally as its servlet container,
so mixing those libraries can seriously confuse things -- as you've seen.

 Yesterday, I tried to install from a fresh tomcat build and I
 started getting the earlier mentioned exceptions when I added the
 required Jboss client jars. So, this means that Jboss jars might
 have same class which catalina.jar have but I am wondering howcome
 same setup is working fine for other environments.

I'm just going to go ahead and say that this is not a supported
configuration and leave it at that. It could take a while to figure
out the exact combination of offending libraries and classes, but it's
just not worth it: you need to change the way you deploy.

If you need EJB and don't want to use JBoss, consider using TomEE: it
uses Tomcat as its servlet container and provider DJB support using
OpenEJB. So if you're looking for something lighter than JBoss, take a
look at TomEE.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPsMZAAoJEBzwKT+lPKRYkWgP/Ai3ihS6qLiqRsXJWMosRgh/
aqRa6mzhKt6+31lmpgZyGvrthkmTzWCiomoYGDNI8bin55hfCaTahs0mOdzrVIKP
EeGTaVT4T3XJGvI79iB/VfI8665h/qOTL+BU8qc1NLd2WMooqEb5KrgCqL6PGdni
/lsTnahVk2/C/u9qCO11wd5JsY+AkFGCeWPUqVLQqsn9u3hw9Xm79kYkGJRSiIM4

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Thursday, April 03, 2014 5:27 PM
 To: Tomcat Users List
 Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work

 Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

  André,

  On 4/3/14, 3:34 PM, André Warnier wrote:
  Alten, Jessica-Aileen wrote:
  -Ursprüngliche Nachricht- Von: André Warnier
  [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014
  15:36 An: Tomcat Users List Betreff: Re: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work

  Alten, Jessica-Aileen wrote:
  A bit guessing here :

  You have :
  worker.ajp13w.host=localhost
  and

  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
  (errno=49)
  is localhost == 0.0.0.0  ?

  From the point of view of mod_jk/isapi, should it not be
  127.0.0.1 ?
  Your answer points to the right direction. 0.0.0.0 means: any
  configured IPv4-Address on this computer, see

  http://serverfault.com/questions/78048/whats-the-difference-
 betwee
  n-
  ip
  -addre ss-0-0-0-0-and-127-0-0-1

  In principle this is ok at first. The Ajp13 Connector was
  configured in server.xml to listen at any IPv4 address on port
  8009 - which is the default setting. But the connector can't find
  any suitable
  address.
  The problem is: The new Tomcat-Connector can't parse
  worker.ajp13w.host=localhost, instead localhost must be
 replaced
  with 127.0.0.1, this works!

  In my eyes this is a big fat bug, because most documentation on
  workers use localhost. localhost is actually the default for
 the
  host connection directive.

  The new worker directive prefer_ipv6 doesn't change this
  behavior.

  Hi.

  Can you please really check this ?

  Open a command window on that server, and do ping localhost.
  It should tell you what it understands by localhost. Copy and
  paste the result here :
  ping localhost

  Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
  Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
  127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
  Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms
  TTL=128

  Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4,
  Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
  Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

  That /is/ bizarre.  As far as I know, to resolve hostnames in its
  configuration, mod_jk/isapi is using the OS's resolver library, the
  same as the one ping should be using. On the other hand, you say
  that if you have

  worker.ajp13w.host=localhost
  it doesn't work (mod_jk cannot connect to tomcat), but when you
  change this to

  worker.ajp13w.host=127.0.0.1
  then it works fine.

  Ok, another check in a command window (and I assume that you open
  this command window *on the server itself* where mod_jk and Tomcat
  are running, right ?)

  test :

  1) telnet localhost 8009

  2) telnet 127.0.0.1 8009

  Any difference between these 2 cases ?

  If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39
  problem.

  In any case, you cannot connect to 0.0.0.0, as this log line would
  suggest :

  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed

  Could this be an interaction between IPv4 and IPv6? Try:

  C: nslookup localhost

  You might get only 127.0.0.1 or you might also get :: (or something
  equivalent). I'm not sure why it wasn't happening with earlier
  versions of mod_jk (which?).

 (versions : her first post mentioned the versions she was comparing)

 I previously asked Jessica-Aileen to do a ping localhost on the
 machine, see results above.  It definitiely pings 127.0.0.1 ..
 (assuming it was done on the same machine)

 And I don't think that nslookup uses the local resolver.
 When I'm doing that on my Windows laptop, for localhost it responds
 not found (in many more German words)

 C:\Dokumente und Einstellungen\awnslookup localhost
 Server:  fire-see.localdomain
 Address:  192.168.245.253

 *** localhost wurde von fire-see.localdomain nicht gefunden: Non-
 existent domain

 On the other hand, it does this (spot the difference..):

 C:\Dokumente und Einstellungen\awnslookup localhost.
 Server:  fire-see.localdomain
 Address:  192.168.245.253

 Name:localhost
 Address:  127.0.0.1

 (But that of course could be the localhost of my DNS server, since it
 happens to be a Linux box running dnsmasq, and it has that name in it's
 own hosts file.)

This result is understandable, as the nslookup tool is a DNS resolver tool.  
It's designed to query the DNS system directly, avoiding the systems resolver 
and any caching. Not exactly sure why it resolves localhost., but adding the 
final period tells it not to append the default domain.  In other words, 
localhost. Is a top-level domain.  Perhaps there is a special case built into 
the DNS system for

Re: AW: grab hostname from tomcat manager

2014-04-04 Thread Frederik Nosi


Hi,

On 04/02/2014 04:54 PM, bjoern.bec...@easycash.de wrote:

-Ursprüngliche Nachricht-
Von: André Warnier [mailto:a...@ice-sa.com]
Gesendet: Mittwoch, 2. April 2014 16:35
An: Tomcat Users List
Betreff: Re: grab hostname from tomcat manager

bjoern.bec...@easycash.de wrote:

Hello,

I need to grab the hostname from the tomcat manager somehow.
Unfortunately this URL manager/text/serverinfo doesn't contain the

hostname.

Is there any other smart way to receive the hostname via tomcat

manager app?
For give me for asking, but how do you access the tomcat manager if you
do not know the hostname ?

Good question :). But I got a good reason for it.

I got two servers with several tomcat instances.
In front of them is a loadbalancer with is configured to do a failover.

-LB-
 /   \
Server1:8081Server2:8081

I need to write a shell script to sync a specific directory and for each tomcat 
instance I need to know on which one the loadbalancer is targeting at the 
moment.
If tomcat 8081 on server 1 is down, the loadbalancer will point to server 2 
tomcat 8081. I can find it out through the loadbalancer address only.


I think the right source of the information you need is the load 
balancer, if you have access obviously. If not, you have the other 
indirect methods suggested from the others in this thread, jvmRoute or 
a page which shows the hostname.


Beware to the load balancing method used too, source ip, simple round 
robin or other.






-
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



Federik

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

Re: tomcat randomly undeploys and redeploys the applications

2014-04-04 Thread Elias Kopsiaftis

Ive done some more research into this problem with my co developer, and we
have a question. Is it possible that memory leaks would cause tomcat to
crash? Silly question I know, but heres technically what the situation is.
We did not add code to shut down all threads when application is undeployed
through tomcat manager. When undeploying and redeploying we cause memory
leaks due to our application. Now, I guess the real question is, we seem to
always deploy it fine, but randomly at some point during the night it will
crash, and we only know that from checking next morning. We have nothing
logged that indicates why. Would memory leaks cause it to crash randomly
even though nothing is trying to connect to it, yet it would seem to deploy
fine? Could that be the issue we are seeing? Is there any specific class to
debug in logging.properties that might indicate whats going on? I added
that line you guys mentioned about setting log level to DEBUG from that
class loader class, but it hasnt crashed since then


On Thu, Apr 3, 2014 at 12:06 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Mark,

 On 4/2/14, 5:20 PM, Mark Eggers wrote:
  Chris,
 
  On 4/2/2014 1:54 PM, Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  Mark,
 
  On 4/2/14, 4:30 PM, Mark Eggers wrote:
  Chris,
 
  On 4/2/2014 1:05 PM, Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  Chuck,
 
  On 4/2/14, 8:21 AM, Caldarale, Charles R wrote:
  From: Elias Kopsiaftis [mailto:yemi...@gmail.com]
  Subject: tomcat randomly undeploys and redeploys the
  applications
 
  I deploy the application, then in the log file
  catalina.out i get many messages from WebappClassLoader
  clearReferencesThreads saying threads appear to have
  started but have failed to stop
 
  This is an indication that your webapp is not managing its
  threads properly.
 
  then finally, Ill get a message from HostConfig
  checkResources that says its undeploying the context,
  and then it redeploys.
 
  This is sometimes caused by incorrect timestamps on the
  bits of the webapp that Tomcat monitors, or an incorrect
  clock setting on the system Tomcat is running on.  The
  mismatch makes it appear that the webapp is being updated
  continuously.
 
  I've found that in development, a single update can cause
  Tomcat to go into a loop of redeployments, re-deploying my
  web application every few seconds or so. If I let it go, it
  does finally stop reloading and settle down.
 
 
  Can you describe your development environment a little bit,
  and any thoughts as to what might trigger this loop of
  redeployments?
 
  I use Eclipse for development, but our real build process is
  ant-based. We have some watched resources configured outside the
  default (stuff like Struts config files, etc.).
 
 
  Ah, makes sense.
 
  When I do a build while Tomcat is running, usually I get one
  webapp reload, but sometimes I get a series of reloads. It
  usually gets so irritating (our webapp takes about 10 seconds to
  reload) that I just kill Tomcat and immediately restart it. It
  starts up once and all is well after that.
 
 
  Yep, and in the process more files are copied about, and that
  triggers another reload.
 
  Fun, fun.

 No, the deployment update takes like one or two seconds. It's usually
 something like copying less than 10 class files or whatever. It's
 nearly instantaneous. Whatever happens, it's not because I'm updating
 files during the reload. I could understand that situation.

 What I observe is that I update my application, I wait maybe 10
 seconds, and then Tomcat reloads my application multiple times before
 I just kill it.

  I've not seen this, but it could explain some issues some the
  developers I support are seeing.
 
  It definitely happens, and I never remember to enable the DEBUG
  logging to find out what resource it thinks has been updated
  until after it happens, at which point I just don't care. Perhaps
  I should enable it right now :)
 
  - -chris
 
  I've managed to make this happen in my environment now (NetBeans
  7.4, Maven 3.2.1, Tomcat 7.0.42 - all will be upgraded soon). I
  just needed an application that takes a bit longer to load. I only
  managed to trigger two reloads, so it's not much of an issue.
 
  Maybe look at adding the backgroundProcessorDelay attribute to the
  context? I don't know what would happen if the context got a string
  of reload requests within the delay interval. Would it queue them
  up one after the other, or would it just execute one?

 I think it's more important to see what file(s) Tomcat thinks is(are)
 being updated. I wonder if it's the same file, or if there's some
 weird timestamp issue happening. Perhaps there is even some kind of
 edge case where a resource's last-modified date isn't being updated
 properly.

 In most cases, Tomcat reloads my application a single time, as
 expected.

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Saurabh,

On 4/4/14, 1:19 AM, Saurabh Saraswat wrote:
 I am doing connection pooling with tomcat 7.0.39 and MySQL
 5.5.After searching on google and with your help i have done the
 below things. Even i am able to get the connection successfully
 using this but getting some trouble and exception. I am explaining
 you all steps done by me-
 
 [snip]
 
 *3. Then on my servlet i am getting the object of connection like
 this-*
 
 private static InitialContext ic; protected static DataSource
 datasource; private static Context ctx;

You shouldn't use class members for these: instead, do everything
locally in your getConnection method. It will make your servlet less
prone to error. If you want to fetch the DataSource one single time,
do it in a ServletContextListener and place the DataSource into the
application scope.

Just don't fetch it with every request and store it into a static
class member: you may run into odd thread behavior if you do this.

 public void doSomeStuff() throws DatabaseException { Connection
 conn = null; try { conn= getConnection();
 
 . // do the required stuff
 
 } catch (Exception ex) {
 
 } finally { conn.close(); } }

Don't forget to:

1. wrap a try/catch block around conn.close: you don't want an
SQLException thrown from conn.close to mask any exception that is in
the process of being thrown. In the method above, you are catching all
exceptions (but not Throwables like NoSuchMethodError, etc.) so you
could still mask things.

2. Close all other JDBC resources you use (Statement, ResultSet).

3. Catch all exceptions/errors if rollback is a possibility.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPsqKAAoJEBzwKT+lPKRYNcQQAK3oNKSgXuCa1f3mFN/m/jPD
2YYkhmSFu7YpPdB6sZNvPPiPlce7Ddbxmqq9Rd84jhbxvn4C2cy0cNV7GAoJ7x8i
FnW+4UWGnnDKW3+9dS8D5JsdRbhplGYwdFWKI4smxXuZf+bUfvnpltQvtnVqacC8
cQu8tFy6XtlnxozlGKSurk4/6T+oqMSwneeuQxIh9bUvU3EwnX3aJGwcTvSNXJCk
vDOTQx+Z21Fv0CB0so33c/XfOKjB9r61zZs3GXahtpq3suCbi9Ch5hFv/FB9mjc9
cl4tGyzlbrV0kVpz4WSG9Q+/12bXt4W9aWamCH6ruZ1ddqeF9ONRmbb9dV1YZchK
Tf+/7WFB3o0Zn73/kYaDtnv1fOYBR0zDVIcO5zFNVvskLTMMzR55O2U+amujY/Aq
niPUPvBudf63H075DFJWj+9NeFUUduCgYUUgd+mmwj7PtN/0+Yu3RkUqUOEQbg0Y
OUqKrLw9G9EUYcNWlIrUk5U9PbN0pvNNpZ+jcKnYGQijSFkvWqX78YqZ5kP9yHVl
xJx0YwqL1UGZAjYUNZ276FVeA/UhVWInXzCRdjBmAvp8n6TrI39l0mftwtAh6AOQ
tyIPGio+Uvz9QrKl8azSRWQVIuwhEZcYluCn+M8zdc9yDq5u+bpNCoZxp7O50G9j
NMpO/UMsFes4OEOZTp+Q
=tV3f
-END PGP SIGNATURE-

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

Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 4/4/14, 8:57 AM, Daniel Mikusa wrote:
 On Apr 4, 2014, at 8:22 AM, Saurabh Saraswat
 ssaras...@pivotalindia.com wrote:
 
 Dear Dan,
 
 Thanks for your response!
 
 I have cross checked the user / password configuration. All is
 correct.
 
 If you’re getting “Access Denied” exceptions, there is only one
 cause and that’s bad credentials (or host + credentials, because
 MySQL can limit access based on the host).  If you’re not seeing
 these any more then, disregard.

I've never tried this, but it could also be due to connection-limits
on the server itself. Having root limited to a certain number of
connections sounds like a terrible idea, but then again, so does
connecting as root in the first place.

 As i mentioned that initially i am getting the object of
 connection but after some time (After few hits to database from
 application) my web app goes to slow and than it stops working i
 i got the below exception- 
 *org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a
 connection, pool error Timeout waiting for idle object*
 
 +1 to David’s suggestion.  You could be leaking connections or your
 queries are very slow.

+1

 Two suggestions:
 
 1.) Enable the slow query log on your MySQL server and see if the
 queries are slow.  Alternatively, login to your MySQL server and
 run ‘show processlist”.  That will show you what queries are
 running.

+1

 2.) Enable DBCP’s abandoned connection detection.  See the
 “removeAbandoned” attribute.

+10

 With this (and logAbandoned), the pool will alert you when your
 application does not properly return connections to the pool.

In development, I always recommend that you use maxActive=1 for your
connection pools. This will expose any potential deadlocks you may
have mistakenly coded into your application.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPssiAAoJEBzwKT+lPKRYTx4QAK8a4WJIx1i+yWyZquSrCnad
RBNB69jnPmYG0Uzc/yKyHzOXvv2wt1vE22wYyp64b4FFVqQNBmEnnm6XI20PSR2i
Yt9lm5wZ5/5fsCGvj39B8E11GCao5enzkhXUpa51spLnjHfw5k3o0gGmWAqhLVza
nOfbG+rTjjjXCrr1Y6tz0g+35M+w02TIh87Z5xdkvboqv/NRfxbGKRIZB2e1zT0K
USY4skgug3L1TpKiXgoRNv7g7gbxHB7AXgL1po+PI1T1mNXCakUE81O26Etv/wm2
1A/d15LfCLou0uWQSfHPqaoODGFVOTsRWwn8xiJdjo2Ah/y7OqXfzMQh41UBO8H7
jNmakIHlb6NYDJK6LiRFlGw5K9AEO+dNFJ9e6Gi4kELB4Kn6CGqFRD3aqTsVerOb
EhEG844nDmVRzr7gwK58aXSICy8PURDOfmZ+IaXehz0MARnKQiog3cWBT+EKIHxq
RUAc0T/YEG+Qm1jiZef5h+NuMZLrzczQIOXXGYkjcMwGcUxmjzBbbvYbr56g84jL
3ukIXp6bnOvyIdB8jnibbICoR/sj0Mg4zia7vTPkqdXbU3Ng2W6/lV9K2Mnm9aDL
OcLocnWnFGZycukIDYtfbtZOY7wTAqk5fJsZauDQGeeA4M9UXu4dPgpaoahuK8Dq
moJwtEq/5/JNXkctdS7n
=RI4v
-END PGP SIGNATURE-

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

Re: tomcat randomly undeploys and redeploys the applications

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Elias,

On 4/4/14, 11:03 AM, Elias Kopsiaftis wrote:
 Ive done some more research into this problem with my co developer,
 and we have a question. Is it possible that memory leaks would
 cause tomcat to crash?

Yes, but you'll likely get an OutOfMemoryError in your log, and then
everything will go crazy. Some requests will work, others will not.
Things will get slow. For us, the background thread often quits and
sessions never expire, exacerbating the problem.

But it won't happen silently (you may have to look for it) and it
won't spontaneously undeploy and redeploy your web application.

 Silly question I know, but heres technically what the situation
 is.
 
 We did not add code to shut down all threads when application is
 undeployed through tomcat manager.

Tomcat will do this itself: you don't need to add any code. Or did you
mean that you have Threads created by your application that continue
to tun after your web app has been shut down?

 When undeploying and redeploying we cause memory leaks due to our
 application.

Yes, this can happen. The Threads cause the WebappClassLoader to stay
in memory, which means that all Class objects for the previous
deployment are still hanging around. It can be several tens of MiB per
reload.

You should read this excellent presentation which explains the
problem(s) and the solution(s):
http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

 Now, I guess the real question is, we seem to always deploy it
 fine, but randomly at some point during the night it will crash,
 and we only know that from checking next morning.

What do you mean when you say crash? Exception? Spontaneous
re-deployment? OutOfMemory? JVM crash (process exits)?

 We have nothing logged that indicates why.

If the process is gone without any indication of why (no shutdown
message, no nothing), my only guess is Linux OOM-killer. You never
actually came back to describe the environment you are in after saying
you'd post that information later today. If you're not on Linux
I'm not sure.

 Would memory leaks cause it to crash randomly even though nothing
 is trying to connect to it, yet it would seem to deploy fine?

I've never seen an OOME actually cause a JVM to quit. It just slogs
onward, often not able to accomplish any useful work, but the process
stays running.

 Could that be the issue we are seeing? Is there any specific class
 to debug in logging.properties that might indicate whats going on?
 I added that line you guys mentioned about setting log level to
 DEBUG from that class loader class, but it hasnt crashed since
 then

Describe what you mean by crash, including as much details about it,
and definitely read the presentation referenced above. Also definitely
fix your web application to shut down its Threads. Whatever component
launches them (e.g. ServletContextListener, Servlet.init, etc.) should
stop them in the appropriate callback method
(ServletContextListener.contextDestroyed, Servlet.destroy, etc.).

- -chris

 On Thu, Apr 3, 2014 at 12:06 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Mark,
 
 On 4/2/14, 5:20 PM, Mark Eggers wrote:
 Chris,
 
 On 4/2/2014 1:54 PM, Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Mark,
 
 On 4/2/14, 4:30 PM, Mark Eggers wrote:
 Chris,
 
 On 4/2/2014 1:05 PM, Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Chuck,
 
 On 4/2/14, 8:21 AM, Caldarale, Charles R wrote:
 From: Elias Kopsiaftis [mailto:yemi...@gmail.com] 
 Subject: tomcat randomly undeploys and redeploys
 the applications
 
 I deploy the application, then in the log file 
 catalina.out i get many messages from
 WebappClassLoader clearReferencesThreads saying
 threads appear to have started but have failed to
 stop
 
 This is an indication that your webapp is not
 managing its threads properly.
 
 then finally, Ill get a message from HostConfig 
 checkResources that says its undeploying the
 context, and then it redeploys.
 
 This is sometimes caused by incorrect timestamps on
 the bits of the webapp that Tomcat monitors, or an
 incorrect clock setting on the system Tomcat is
 running on.  The mismatch makes it appear that the
 webapp is being updated continuously.
 
 I've found that in development, a single update can
 cause Tomcat to go into a loop of redeployments,
 re-deploying my web application every few seconds or
 so. If I let it go, it does finally stop reloading and
 settle down.
 
 
 Can you describe your development environment a little
 bit, and any thoughts as to what might trigger this loop
 of redeployments?
 
 I use Eclipse for development, but our real build process
 is ant-based. We have some watched resources configured
 outside the default (stuff like Struts config files,
 etc.).
 
 
 Ah, makes sense.
 
 When I do a build while Tomcat is running, usually I get
 one webapp reload, but sometimes I get a series

Re: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
 I've not followed the complete thread, but if the server is a *nix 
 implementation, the better diag tool might be dig.

No, you haven't been following it well. The subject pretty much
rules-out a *NIX environment ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPs2OAAoJEBzwKT+lPKRYtFUP/i80QgR+0ZrDjsn7sCceJ5yn
uksnWkLAsWtpNn8hVPe7t2dHrwyAIDiz32PhEy493EKniCjnvuF74lfHuLpCfYax
n8Ju57djYTuEEI5+R1MYDsacJlnG0f8KKgA8RIAl8wFKED0O7D6wzA5bNj0mh6eO
Bqa04hTKEX5XfEaBdX6czhmgZjc+fBCw6l3nSG/+S1meFzxCggluAgceU7HdPlRG
gvjTJz/qRrfNdWTcZMry7ryFS2vYp5A7QloYV1nE6a9Ujw6s1k6sLkCBR8lfCMum
9ossRGkDdlRvJcaCZkLB7W/Cur+zzYwCw87F5OqQGP6fmaZgA1QmENy4KeXTNx6Y
2CmhDEh0U64NVGqjM/zhNX0MfVv70rOGOa6PcUJ/VkEwNRfEoaSHSURX39pPoTkG
v3xlA+TrTfQ+0kdYtUsz6bhrkrZWwLsrn39S3qrpPI+1KIzED+ejcEm0DIiCXl8B
e+ZplZv7jDLoP0GCqu+KwJMrx81bJk8KGQli5HgnFJAa/S8oR8UXLVS2GXHIg4bb
Rb8ucmW6DBT/ugJZ96sCktEZTrlPe8Ds2ho8OZvQFLrOXxUkKqo3eNzRtEiBDWF7
e9Lz8OkJXdyYh3GrsucUQYnjmlh2OkpEUiZnZaHKLTDrP4ILk3/FcxrVOfyTwKQl
/294/H1UfXoAKDbwYBwg
=F5eV
-END PGP SIGNATURE-

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

Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
 -Original Message- From: André Warnier
 [mailto:a...@ice-sa.com] Sent: Thursday, April 03, 2014 5:27 PM To:
 Tomcat Users List Subject: Re: AW: AW:
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
 Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 André,
 
 On 4/3/14, 3:34 PM, André Warnier wrote:
 Alten, Jessica-Aileen wrote:
 -Ursprüngliche Nachricht- Von: André Warnier 
 [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
 2014 15:36 An: Tomcat Users List Betreff: Re: AW: 
 tomcat-connectors-1.2.39-windows-x86_64-iis does not
 work
 
 Alten, Jessica-Aileen wrote:
 A bit guessing here :
 
 You have :
 worker.ajp13w.host=localhost
 and
 
 jk_open_socket::jk_connect.c (735): connect to 
 0.0.0.0:8009
 failed
 (errno=49)
 is localhost == 0.0.0.0  ?
 
 From the point of view of mod_jk/isapi, should it not
 be
 127.0.0.1 ?
 Your answer points to the right direction. 0.0.0.0
 means: any configured IPv4-Address on this computer,
 see
 
 http://serverfault.com/questions/78048/whats-the-difference-

 
betwee
 n-
 ip
 -addre ss-0-0-0-0-and-127-0-0-1
 
 In principle this is ok at first. The Ajp13 Connector
 was configured in server.xml to listen at any IPv4
 address on port 8009 - which is the default setting.
 But the connector can't find any suitable
 address.
 The problem is: The new Tomcat-Connector can't parse 
 worker.ajp13w.host=localhost, instead localhost must
 be
 replaced
 with 127.0.0.1, this works!
 
 In my eyes this is a big fat bug, because most
 documentation on workers use localhost. localhost is
 actually the default for
 the
 host connection directive.
 
 The new worker directive prefer_ipv6 doesn't change
 this behavior.
 
 Hi.
 
 Can you please really check this ?
 
 Open a command window on that server, and do ping
 localhost. It should tell you what it understands by
 localhost. Copy and paste the result here :
 ping localhost
 
 Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32
 Bytes Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
 TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort
 von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
 
 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4,
 Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben
 in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert =
 0ms
 
 
 That /is/ bizarre.  As far as I know, to resolve hostnames in
 its configuration, mod_jk/isapi is using the OS's resolver
 library, the same as the one ping should be using. On the
 other hand, you say that if you have
 
 worker.ajp13w.host=localhost
 it doesn't work (mod_jk cannot connect to tomcat), but when
 you change this to
 
 worker.ajp13w.host=127.0.0.1
 then it works fine.
 
 Ok, another check in a command window (and I assume that you
 open this command window *on the server itself* where mod_jk
 and Tomcat are running, right ?)
 
 test :
 
 1) telnet localhost 8009
 
 2) telnet 127.0.0.1 8009
 
 Any difference between these 2 cases ?
 
 If not, then indeed it looks like a mod_jk/isapi_redirect
 1.2.39 problem.
 
 In any case, you cannot connect to 0.0.0.0, as this log
 line would suggest :
 
 jk_open_socket::jk_connect.c (735): connect to 
 0.0.0.0:8009
 failed
 
 Could this be an interaction between IPv4 and IPv6? Try:
 
 C: nslookup localhost
 
 You might get only 127.0.0.1 or you might also get :: (or
 something equivalent). I'm not sure why it wasn't happening
 with earlier versions of mod_jk (which?).
 
 (versions : her first post mentioned the versions she was
 comparing)
 
 I previously asked Jessica-Aileen to do a ping localhost on
 the machine, see results above.  It definitiely pings 127.0.0.1
 .. (assuming it was done on the same machine)
 
 And I don't think that nslookup uses the local resolver. When I'm
 doing that on my Windows laptop, for localhost it responds not
 found (in many more German words)
 
 C:\Dokumente und Einstellungen\awnslookup localhost Server:
 fire-see.localdomain Address:  192.168.245.253
 
 *** localhost wurde von fire-see.localdomain nicht gefunden:
 Non- existent domain
 
 On the other hand, it does this (spot the difference..):
 
 C:\Dokumente und Einstellungen\awnslookup localhost. Server:
 fire-see.localdomain Address:  192.168.245.253
 
 Name:localhost Address:  127.0.0.1
 
 (But that of course could be the localhost of my DNS server,
 since it happens to be a Linux box running dnsmasq, and it has
 that name in it's own hosts file.)
 
 This result is understandable, as the nslookup tool is a DNS
 resolver tool.  It's designed to query the DNS system directly,
 avoiding the systems resolver and any caching. Not exactly sure why
 it resolves localhost., but adding the final period tells it not
 to append the default domain.  In other words, localhost. Is a
 top-level domain.  Perhaps there is a special case

Re: tomcat randomly undeploys and redeploys the applications

2014-04-04 Thread Elias Kopsiaftis

Im sorry about that. The reason I did not post same day was that through
the messages in this thread someone suggested adding a debug statement to
debug WebappClassLoader, and I wanted to wait to see if it happened again
so I could see the debug output, then I came up with the idea in my last
message. yes we are on Linux and we are using java 7 and tomcat 7 and we
are on linux 3.11.6 on a 64 bit build for x86. When I say crash, I mean
that when we use the client application to connect to the web app it wont
connect and we have to go into tomcat manager and start it back up. We use
an executor with 20 threads in it to process things on the server, and that
was never shut down, so that would explain the memory leak and the extra
threads. We need them to run for the duration of the application life
cycle, but they should be cleaned up on undeployment. Thanks for the
reference to the presentation. I will go through it now. I think I may have
my answer and hopefully this wont happen again after we fix our web app to
shut down those threads.


On Fri, Apr 4, 2014 at 11:17 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Elias,

 On 4/4/14, 11:03 AM, Elias Kopsiaftis wrote:
  Ive done some more research into this problem with my co developer,
  and we have a question. Is it possible that memory leaks would
  cause tomcat to crash?

 Yes, but you'll likely get an OutOfMemoryError in your log, and then
 everything will go crazy. Some requests will work, others will not.
 Things will get slow. For us, the background thread often quits and
 sessions never expire, exacerbating the problem.

 But it won't happen silently (you may have to look for it) and it
 won't spontaneously undeploy and redeploy your web application.

  Silly question I know, but heres technically what the situation
  is.
 
  We did not add code to shut down all threads when application is
  undeployed through tomcat manager.

 Tomcat will do this itself: you don't need to add any code. Or did you
 mean that you have Threads created by your application that continue
 to tun after your web app has been shut down?

  When undeploying and redeploying we cause memory leaks due to our
  application.

 Yes, this can happen. The Threads cause the WebappClassLoader to stay
 in memory, which means that all Class objects for the previous
 deployment are still hanging around. It can be several tens of MiB per
 reload.

 You should read this excellent presentation which explains the
 problem(s) and the solution(s):

 http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

  Now, I guess the real question is, we seem to always deploy it
  fine, but randomly at some point during the night it will crash,
  and we only know that from checking next morning.

 What do you mean when you say crash? Exception? Spontaneous
 re-deployment? OutOfMemory? JVM crash (process exits)?

  We have nothing logged that indicates why.

 If the process is gone without any indication of why (no shutdown
 message, no nothing), my only guess is Linux OOM-killer. You never
 actually came back to describe the environment you are in after saying
 you'd post that information later today. If you're not on Linux
 I'm not sure.

  Would memory leaks cause it to crash randomly even though nothing
  is trying to connect to it, yet it would seem to deploy fine?

 I've never seen an OOME actually cause a JVM to quit. It just slogs
 onward, often not able to accomplish any useful work, but the process
 stays running.

  Could that be the issue we are seeing? Is there any specific class
  to debug in logging.properties that might indicate whats going on?
  I added that line you guys mentioned about setting log level to
  DEBUG from that class loader class, but it hasnt crashed since
  then

 Describe what you mean by crash, including as much details about it,
 and definitely read the presentation referenced above. Also definitely
 fix your web application to shut down its Threads. Whatever component
 launches them (e.g. ServletContextListener, Servlet.init, etc.) should
 stop them in the appropriate callback method
 (ServletContextListener.contextDestroyed, Servlet.destroy, etc.).

 - -chris

  On Thu, Apr 3, 2014 at 12:06 PM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  Mark,
 
  On 4/2/14, 5:20 PM, Mark Eggers wrote:
  Chris,
 
  On 4/2/2014 1:54 PM, Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  Mark,
 
  On 4/2/14, 4:30 PM, Mark Eggers wrote:
  Chris,
 
  On 4/2/2014 1:05 PM, Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  Chuck,
 
  On 4/2/14, 8:21 AM, Caldarale, Charles R wrote:
  From: Elias Kopsiaftis [mailto:yemi...@gmail.com]
  Subject: tomcat randomly undeploys and redeploys
  the applications
 
  I deploy the application, then in the log file
  catalina.out i get many messages from
  WebappClassLoader

Re: catalina.out anomaly?

2014-04-04 Thread Shanti Suresh

Hi Chris,

Thanks you for the note!


On Thu, Apr 3, 2014 at 12:40 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Shanti,


 They work the same way. Are you launching them differently for
 different versions?


Yes, actually.   The logging.properties file and the catalina.properties
file are the same.
 The JVM arguments are the same as well between the two versions.  But I am
using Executor ThreadPool in 7.0.52.  Let me revert to not using an
Executor ThreadPool and see what goes on.





 At some point, Tomcat was modified to adhere to some rulings made by
 the Servlet EG about JAR-scanning and other (unfortunately)
 time-consuming operations. You can speed-up Tomcat startup by using
 metadata-complete=true in your web.xml, and configuring the various
 JAR-scanning options.


 https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#JAR_Scanning


Please see your comment below.

If your context is not deployed, then your web application will not
 respond to requests. Are you sure you don't want it deployed?

 I mean, why does 7.0.23 not take forever to deploy these same 136 contexts
while 7.0.52 does?  If I could only see where the output of 7.0.23 goes,
I'll know better.  I don't see any swallowOutput on the Default context.
So I am unsure what's going on with 7.0.23.  I only see [Unloading
class.. messages because of the  -XX:+ClassUnloading JVM argument.


That is a very long time. Can you take some thread dumps during the
 process. You certainly have a long time for that opportunity.

 Yes!  Good point!  Should have thought of that.


  (2) Catalina.out messages:
 
  v7.0.23 catalina.out is empty.

 How do you launch Tomcat 7.0.23?

 Through /bin/service which invokes a start_tomcat script which invokes the
startup.sh Tomcat script.


 So Tomcat is deploying context_136 which is presumably your web
 application. Why does your web application take so long to launch?


Tomcat deploys 136 contexts.  Each context is a website.  Takes about 5-6
seconds to deploy each context.  Now 7.023 is pretty quick.  I'll compare
thread dumps between the two startups.  Unless you can think of something
else that could prevent startup messages not showing up in 7.0.23's
catalina.out.  BTW, the startup messages go nowhere in 7.0.23.



 So you want Tomcat to come up immediately without any applications
 available? That's no fun.

 I agree :-)  But that's not what I meant.  I didn't want context to be
deployed if I can save their meta-data somehow from the previous run of
Tomcat which the server can reuse.


  I don't think JARs are scanned in 7.0.52 for things to slow down so
  much.

 Are you sure? Take thread dumps.


Yes, I will do so.



  Not sure if metadata-complete=true will help here.  Running all
  the FIleHandlers in FINEST mode shows nothing while contexts are
  being deployed.

 Then you have done something wrong. When I set level=FINEST, I get so
 much logging it noticeably slows down the startup of my Tomcat instance.


 Hmm..



 How long does Tomcat take to launch if you have no web applications?


INFO: Server startup in 1454 ms

Well, the executor threadpool is a suspect.  Let me work in making 7.0.52
like 7.0.23 in all respects, take thread dumps and then check things out.
Please let me know if the Executor threadpool can be slow.  And, in the
meantime, also how I might make catalina.out talk in 7.0.23.  I know I am
doing something silly but I can't seem to figure this one out.

Thanks!

  -Shanti

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, April 04, 2014 10:23 AM
 To: Tomcat Users List
 Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jeffrey,

 On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
  -Original Message- From: André Warnier [mailto:aw@ice-
 sa.com]
  Sent: Thursday, April 03, 2014 5:27 PM To:
  Tomcat Users List Subject: Re: AW: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work

  Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

  André,

  On 4/3/14, 3:34 PM, André Warnier wrote:
  Alten, Jessica-Aileen wrote:
  -Ursprüngliche Nachricht- Von: André Warnier
  [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
  2014 15:36 An: Tomcat Users List Betreff: Re: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work

  Alten, Jessica-Aileen wrote:
  A bit guessing here :

  You have :
  worker.ajp13w.host=localhost
  and

  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
  (errno=49)
  is localhost == 0.0.0.0  ?

  From the point of view of mod_jk/isapi, should it not be
  127.0.0.1 ?
  Your answer points to the right direction. 0.0.0.0
  means: any configured IPv4-Address on this computer, see

  http://serverfault.com/questions/78048/whats-the-difference-

 betwee
  n-
  ip
  -addre ss-0-0-0-0-and-127-0-0-1

  In principle this is ok at first. The Ajp13 Connector was
  configured in server.xml to listen at any IPv4 address on port
  8009 - which is the default setting.
  But the connector can't find any suitable
  address.
  The problem is: The new Tomcat-Connector can't parse
  worker.ajp13w.host=localhost, instead localhost must be
  replaced
  with 127.0.0.1, this works!

  In my eyes this is a big fat bug, because most documentation on
  workers use localhost. localhost is actually the default for
  the
  host connection directive.

  The new worker directive prefer_ipv6 doesn't change this
  behavior.

  Hi.

  Can you please really check this ?

  Open a command window on that server, and do ping localhost.
 It
  should tell you what it understands by localhost. Copy and
  paste the result here :
  ping localhost

  Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
  Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
  TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort
  von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
  Bytes=32 Zeit1ms TTL=128

  Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen =
 4,
  Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum
 =
  0ms, Maximum = 0ms, Mittelwert = 0ms

  That /is/ bizarre.  As far as I know, to resolve hostnames in its
  configuration, mod_jk/isapi is using the OS's resolver library,
 the
  same as the one ping should be using. On the other hand, you say
  that if you have

  worker.ajp13w.host=localhost
  it doesn't work (mod_jk cannot connect to tomcat), but when you
  change this to

  worker.ajp13w.host=127.0.0.1
  then it works fine.

  Ok, another check in a command window (and I assume that you open
  this command window *on the server itself* where mod_jk and Tomcat
  are running, right ?)

  test :

  1) telnet localhost 8009

  2) telnet 127.0.0.1 8009

  Any difference between these 2 cases ?

  If not, then indeed it looks like a mod_jk/isapi_redirect
  1.2.39 problem.

  In any case, you cannot connect to 0.0.0.0, as this log line
  would suggest :

  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed

  Could this be an interaction between IPv4 and IPv6? Try:

  C: nslookup localhost

  You might get only 127.0.0.1 or you might also get :: (or something
  equivalent). I'm not sure why it wasn't happening with earlier
  versions of mod_jk (which?).

  (versions : her first post mentioned the versions she was
  comparing)

  I previously asked Jessica-Aileen to do a ping localhost on the
  machine, see results above.  It definitiely pings 127.0.0.1 ..
  (assuming it was done on the same machine)

  And I don't think that nslookup uses the local resolver. When I'm
  doing that on my Windows laptop, for localhost it responds not
  found (in many more German words)

  C:\Dokumente und Einstellungen\awnslookup localhost Server:
  fire-see.localdomain Address:  192.168.245.253

  *** localhost wurde von fire-see.localdomain nicht gefunden:
  Non- existent domain

  On the other hand, it does this (spot the difference..):

  C:\Dokumente und Einstellungen\awnslookup localhost. Server:
  fire-see.localdomain Address:  192.168.245.253

  Name:localhost Address:  127.0.0.1

  (But that of course could be the localhost of my DNS server, since
  it happens to be a Linux box running dnsmasq, and it has that name
 in
  it's own hosts file.)

  This result is understandable, as

RE: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, April 04, 2014 10:20 AM
 To: Tomcat Users List
 Subject: Re: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
 does not work

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jeffrey,

 On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
  I've not followed the complete thread, but if the server is a *nix
  implementation, the better diag tool might be dig.

 No, you haven't been following it well. The subject pretty much rules-
 out a *NIX environment ;)

Touché

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

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Friday, April 04, 2014 12:04 PM
 To: 'Tomcat Users List'
 Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work

  -Original Message-
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Sent: Friday, April 04, 2014 10:23 AM
  To: Tomcat Users List
  Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
  not work

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

  Jeffrey,

  On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
   -Original Message- From: André Warnier [mailto:aw@ice-
  sa.com]
   Sent: Thursday, April 03, 2014 5:27 PM To:
   Tomcat Users List Subject: Re: AW: AW:
   tomcat-connectors-1.2.39-windows-x86_64-iis does not work

   Christopher Schultz wrote:
   -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

   André,

   On 4/3/14, 3:34 PM, André Warnier wrote:
   Alten, Jessica-Aileen wrote:
   -Ursprüngliche Nachricht- Von: André Warnier
   [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
   2014 15:36 An: Tomcat Users List Betreff: Re: AW:
   tomcat-connectors-1.2.39-windows-x86_64-iis does not work

   Alten, Jessica-Aileen wrote:
   A bit guessing here :

   You have :
   worker.ajp13w.host=localhost
   and

   jk_open_socket::jk_connect.c (735): connect to
   0.0.0.0:8009
   failed
   (errno=49)
   is localhost == 0.0.0.0  ?

   From the point of view of mod_jk/isapi, should it not be
   127.0.0.1 ?
   Your answer points to the right direction. 0.0.0.0
   means: any configured IPv4-Address on this computer, see

   http://serverfault.com/questions/78048/whats-the-difference-

  betwee
   n-
   ip
   -addre ss-0-0-0-0-and-127-0-0-1

   In principle this is ok at first. The Ajp13 Connector was
   configured in server.xml to listen at any IPv4 address on
 port
   8009 - which is the default setting.
   But the connector can't find any suitable
   address.
   The problem is: The new Tomcat-Connector can't parse
   worker.ajp13w.host=localhost, instead localhost must be
   replaced
   with 127.0.0.1, this works!

   In my eyes this is a big fat bug, because most documentation
   on workers use localhost. localhost is actually the default
   for
   the
   host connection directive.

   The new worker directive prefer_ipv6 doesn't change this
   behavior.

   Hi.

   Can you please really check this ?

   Open a command window on that server, and do ping localhost.
  It
   should tell you what it understands by localhost. Copy and
   paste the result here :
   ping localhost

   Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
   Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
   TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
 Antwort
   von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
   Bytes=32 Zeit1ms TTL=128

   Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen =
  4,
   Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
 Minimum
  =
   0ms, Maximum = 0ms, Mittelwert = 0ms

   That /is/ bizarre.  As far as I know, to resolve hostnames in
 its
   configuration, mod_jk/isapi is using the OS's resolver library,
  the
   same as the one ping should be using. On the other hand, you
   say that if you have

   worker.ajp13w.host=localhost
   it doesn't work (mod_jk cannot connect to tomcat), but when you
   change this to

   worker.ajp13w.host=127.0.0.1
   then it works fine.

   Ok, another check in a command window (and I assume that you
 open
   this command window *on the server itself* where mod_jk and
   Tomcat are running, right ?)

   test :

   1) telnet localhost 8009

   2) telnet 127.0.0.1 8009

   Any difference between these 2 cases ?

   If not, then indeed it looks like a mod_jk/isapi_redirect
   1.2.39 problem.

   In any case, you cannot connect to 0.0.0.0, as this log line
   would suggest :

   jk_open_socket::jk_connect.c (735): connect to
   0.0.0.0:8009
   failed

   Could this be an interaction between IPv4 and IPv6? Try:

   C: nslookup localhost

   You might get only 127.0.0.1 or you might also get :: (or
   something equivalent). I'm not sure why it wasn't happening with
   earlier versions of mod_jk (which?).

   (versions : her first post mentioned the versions she was
   comparing)

   I previously asked Jessica-Aileen to do a ping localhost on the
   machine, see results above.  It definitiely pings 127.0.0.1 ..
   (assuming it was done on the same machine)

   And I don't think that nslookup uses the local resolver. When I'm
   doing that on my Windows laptop, for localhost it responds not
   found (in many more German words)

   C:\Dokumente und Einstellungen\awnslookup localhost Server:
   fire-see.localdomain Address:  192.168.245.253

   *** localhost wurde von fire-see.localdomain nicht gefunden:
   Non- existent domain

   On the other hand, it

Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

I am trying to set up SSL on tomcat with a CA certificate from goDaddy.

I am unable to load the Web Page using HTTPS.

When I try to use a self signed certificate, everything works as expected,
but when I change the keystore to point to the one with the CA certificate
in it, I get nothing. There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

Connector protocol=org.apache.coyote.http11.Http11NioProtocol port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=mykeystore.keystore keystorePass= keyAlias=tcat
clientAuth=false sslProtocol=TLS /

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Friday, April 04, 2014 12:10 PM
 To: 'Tomcat Users List'
 Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work

  -Original Message-
  From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
  Sent: Friday, April 04, 2014 12:04 PM
  To: 'Tomcat Users List'
  Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
  not work

   -Original Message-
   From: Christopher Schultz [mailto:ch...@christopherschultz.net]
   Sent: Friday, April 04, 2014 10:23 AM
   To: Tomcat Users List
   Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
   does not work

   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA256

   Jeffrey,

   On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
-Original Message- From: André Warnier [mailto:aw@ice-
   sa.com]
Sent: Thursday, April 03, 2014 5:27 PM To:
Tomcat Users List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

André,

On 4/3/14, 3:34 PM, André Warnier wrote:
Alten, Jessica-Aileen wrote:
-Ursprüngliche Nachricht- Von: André Warnier
[mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
2014 15:36 An: Tomcat Users List Betreff: Re: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

Alten, Jessica-Aileen wrote:
A bit guessing here :

You have :
worker.ajp13w.host=localhost
and

jk_open_socket::jk_connect.c (735): connect to
0.0.0.0:8009
failed
(errno=49)
is localhost == 0.0.0.0  ?

From the point of view of mod_jk/isapi, should it not be
127.0.0.1 ?
Your answer points to the right direction. 0.0.0.0
means: any configured IPv4-Address on this computer, see

http://serverfault.com/questions/78048/whats-the-
 difference-

   betwee
n-
ip
-addre ss-0-0-0-0-and-127-0-0-1

In principle this is ok at first. The Ajp13 Connector was
configured in server.xml to listen at any IPv4 address on
  port
8009 - which is the default setting.
But the connector can't find any suitable
address.
The problem is: The new Tomcat-Connector can't parse
worker.ajp13w.host=localhost, instead localhost must be
replaced
with 127.0.0.1, this works!

In my eyes this is a big fat bug, because most
 documentation
on workers use localhost. localhost is actually the
default for
the
host connection directive.

The new worker directive prefer_ipv6 doesn't change this
behavior.

Hi.

Can you please really check this ?

Open a command window on that server, and do ping
 localhost.
   It
should tell you what it understands by localhost. Copy and
paste the result here :
ping localhost

Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32
 Bytes
Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
  Antwort
von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
 127.0.0.1:
Bytes=32 Zeit1ms TTL=128

Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen
=
   4,
Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
  Minimum
   =
0ms, Maximum = 0ms, Mittelwert = 0ms

That /is/ bizarre.  As far as I know, to resolve hostnames in
  its
configuration, mod_jk/isapi is using the OS's resolver
 library,
   the
same as the one ping should be using. On the other hand, you
say that if you have

worker.ajp13w.host=localhost
it doesn't work (mod_jk cannot connect to tomcat), but when
 you
change this to

worker.ajp13w.host=127.0.0.1
then it works fine.

Ok, another check in a command window (and I assume that you
  open
this command window *on the server itself* where mod_jk and
Tomcat are running, right ?)

test :

1) telnet localhost 8009

2) telnet 127.0.0.1 8009

Any difference between these 2 cases ?

If not, then indeed it looks like a mod_jk/isapi_redirect
1.2.39 problem.

In any case, you cannot connect to 0.0.0.0, as this log line
would suggest :

jk_open_socket::jk_connect.c (735): connect to
0.0.0.0:8009
failed

Could this be an interaction between IPv4 and IPv6? Try:

C: nslookup localhost

You might get only 127.0.0.1 or you might also get :: (or
something equivalent). I'm not sure why it wasn't happening
 with
earlier versions of mod_jk (which?).

(versions : her first post mentioned the versions she was
comparing)

I previously asked Jessica-Aileen to do a ping localhost on
 the
machine, see results above.  It definitiely pings 127.0.0.1 ..
(assuming it was done on the same machine)

apt-get tomcat7 missing websocket jars

2014-04-04 Thread Sean Winterberger

We just updated to tomcat 7.0.52 using the JSR356 implementation for
websockets.  This implementation is using the annotated class method of
setting up the websocket server endpoint.

On a local install of the system (windows7) the tomcat lib directory
contains tomcat7-websocket.jar and websocket-api.jar, however I do not seem
to be getting those two files from apt-get install tomcat7.

We are using Chef to deploy to multiple instances to AWS and adding the
trust repo to apt to pull down ver 7.0.52 of Tomcat.

deb http://archive.ubuntu.com/ubuntu/ trusty main

We are accessing our websocket server via https, not wss since we are using
AWS ELBs.

After spending a few hours trying to figure out why the connections were
returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
was missing the websocket jars.

Is this working as intended?  Is there a separate apt pkg we can install to
get the proper jars for websocket or do we have to package these jars
ourselves?

Thanks for any help!

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

On Apr 4, 2014, at 1:24 PM, Mark Murphy jmarkmur...@gmail.com wrote:

 I am trying to set up SSL on tomcat with a CA certificate from goDaddy.
 
 I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it?  Please include browser 
behavior and any errors / messages it gives you about the connection.

 
 When I try to use a self signed certificate, everything works as expected,
 but when I change the keystore to point to the one with the CA certificate
 in it, I get nothing.

What steps / instructions did you follow to generate your keystore file?

Dan

 There is nothing in the log that isn't there for the
 Self-Signed startup either.
 
 Here is the Connector declaration:
 
 Connector protocol=org.apache.coyote.http11.Http11NioProtocol port=443
 scheme=https secure=true SSLEnabled=true
 keystoreFile=mykeystore.keystore keystorePass= keyAlias=tcat
 clientAuth=false sslProtocol=TLS /
 
 The keystore contains tcat as one of the three keys. The other two
 entries are root and intermed from goDaddy.
 
 Where can I look to find the issue?


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

Re: apt-get tomcat7 missing websocket jars

2014-04-04 Thread Konstantin Kolinko

2014-04-04 21:59 GMT+04:00 Sean Winterberger sean.winterber...@gmail.com:
 We just updated to tomcat 7.0.52 using the JSR356 implementation for
 websockets.  This implementation is using the annotated class method of
 setting up the websocket server endpoint.

 On a local install of the system (windows7) the tomcat lib directory
 contains tomcat7-websocket.jar and websocket-api.jar, however I do not seem
 to be getting those two files from apt-get install tomcat7.

 We are using Chef to deploy to multiple instances to AWS and adding the
 trust repo to apt to pull down ver 7.0.52 of Tomcat.

 deb http://archive.ubuntu.com/ubuntu/ trusty main

 We are accessing our websocket server via https, not wss since we are using
 AWS ELBs.

 After spending a few hours trying to figure out why the connections were
 returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
 was missing the websocket jars.

 Is this working as intended?  Is there a separate apt pkg we can install to
 get the proper jars for websocket or do we have to package these jars
 ourselves?


1. ASF does not provide those apt files. It is up to Debian devs how
they pack them.

2. It makes perfect sense to move those jars into separate package:
1) They require Java 7
2) They make startup slower, because of annotation scanning that is
needed to detect WebSocket endpoints

https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
https://wiki.apache.org/tomcat/HowTo/FasterStartUp

Best regards,
Konstantin Kolinko

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

Re: apt-get tomcat7 missing websocket jars

On Apr 4, 2014, at 1:59 PM, Sean Winterberger sean.winterber...@gmail.com 
wrote:

 We just updated to tomcat 7.0.52 using the JSR356 implementation for
 websockets.  This implementation is using the annotated class method of
 setting up the websocket server endpoint.
 
 On a local install of the system (windows7) the tomcat lib directory
 contains tomcat7-websocket.jar and websocket-api.jar, however I do not seem
 to be getting those two files from apt-get install tomcat7.
 
 We are using Chef to deploy to multiple instances to AWS and adding the
 trust repo to apt to pull down ver 7.0.52 of Tomcat.
 
 deb http://archive.ubuntu.com/ubuntu/ trusty main
 
 We are accessing our websocket server via https, not wss since we are using
 AWS ELBs.
 
 After spending a few hours trying to figure out why the connections were
 returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
 was missing the websocket jars.
 
 Is this working as intended?  Is there a separate apt pkg we can install to
 get the proper jars for websocket or do we have to package these jars
 ourselves?
 
 Thanks for any help!

Just an FYI, the Debian packages for Tomcat are not maintained by the Tomcat 
project.  There maybe someone on this list who can answer your question, but 
you might be better off asking on a Debian specific mailing list.

Otherwise I’d suggest installing from the tar.gz file here.

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

Install can be as easy as unzipping the file, full instructions can be found in 
the included RUNNING.txt file or online here.

  http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/RUNNING.txt  

Dan



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

Re: apt-get tomcat7 missing websocket jars

2014-04-04 Thread Sean Winterberger

Thanks for the timely response Dan, much appreciated!  Ill bring it up with
the debian mailing list and use the manual install for now.


On Fri, Apr 4, 2014 at 12:11 PM, Daniel Mikusa dmik...@gopivotal.comwrote:

 On Apr 4, 2014, at 1:59 PM, Sean Winterberger sean.winterber...@gmail.com
 wrote:

  We just updated to tomcat 7.0.52 using the JSR356 implementation for
  websockets.  This implementation is using the annotated class method of
  setting up the websocket server endpoint.
 
  On a local install of the system (windows7) the tomcat lib directory
  contains tomcat7-websocket.jar and websocket-api.jar, however I do not
 seem
  to be getting those two files from apt-get install tomcat7.
 
  We are using Chef to deploy to multiple instances to AWS and adding the
  trust repo to apt to pull down ver 7.0.52 of Tomcat.
 
  deb http://archive.ubuntu.com/ubuntu/ trusty main
 
  We are accessing our websocket server via https, not wss since we are
 using
  AWS ELBs.
 
  After spending a few hours trying to figure out why the connections were
  returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
  was missing the websocket jars.
 
  Is this working as intended?  Is there a separate apt pkg we can install
 to
  get the proper jars for websocket or do we have to package these jars
  ourselves?
 
  Thanks for any help!

 Just an FYI, the Debian packages for Tomcat are not maintained by the
 Tomcat project.  There maybe someone on this list who can answer your
 question, but you might be better off asking on a Debian specific mailing
 list.

 Otherwise I'd suggest installing from the tar.gz file here.

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

 Install can be as easy as unzipping the file, full instructions can be
 found in the included RUNNING.txt file or online here.

   http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/RUNNING.txt

 Dan



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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

Created my keystore according to the directions here:
http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x

This is what I see in Chrome:

SSL Connection Error

Unable to make a secure connection to the server. This may be a
problem with the server, or it may be requiring a client
authentication certificate that you don't have.
Error code: ERR_SSL_PROTOCOL_ERROR

Here is a non-SSL URL: http://www.myerstorquetracker.com
With SSL: https://www.myerstorquetracker.com

I am trying to set up SSL on tomcat with a CA certificate from goDaddy.

I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it? Please include browser
behavior and any errors / messages it gives you about the connection.

When I try to use a self signed certificate, everything works as expected,
but when I change the keystore to point to the one with the CA certificate
in it, I get nothing.

What steps / instructions did you follow to generate your keystore file?

Dan

There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

Connector protocol=org.apache.coyote.http11.Http11NioProtocol port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=mykeystore.keystore keystorePass= keyAlias=tcat
clientAuth=false sslProtocol=TLS /

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

On Apr 4, 2014, at 2:52 PM, Mark Murphy jmarkmur...@gmail.com wrote:

Created my keystore according to the directions here:
http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x

Ok. Good start.

This is what I see in Chrome:

SSL Connection Error

Here is a non-SSL URL: http://www.myerstorquetracker.com
With SSL: https://www.myerstorquetracker.com

Interesting. What JVM (java -version) are you using?

Dan

I am trying to set up SSL on tomcat with a CA certificate from goDaddy.

I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it? Please include browser
behavior and any errors / messages it gives you about the connection.

When I try to use a self signed certificate, everything works as expected,
but when I change the keystore to point to the one with the CA certificate
in it, I get nothing.

What steps / instructions did you follow to generate your keystore file?

Dan

There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

1.5.0_15

On Fri, Apr 4, 2014 at 3:23 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
On Apr 4, 2014, at 2:52 PM, Mark Murphy jmarkmur...@gmail.com wrote:

Created my keystore according to the directions here:
http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x

Ok. Good start.

This is what I see in Chrome:

SSL Connection Error

Here is a non-SSL URL: http://www.myerstorquetracker.com
With SSL: https://www.myerstorquetracker.com

Interesting. What JVM (java -version) are you using?

Dan

I am trying to set up SSL on tomcat with a CA certificate from goDaddy.

I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it? Please include browser
behavior and any errors / messages it gives you about the connection.

When I try to use a self signed certificate, everything works as expected,
but when I change the keystore to point to the one with the CA certificate
in it, I get nothing.

What steps / instructions did you follow to generate your keystore file?

Dan

There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

I saw something on StackOverflow that said the key type in the keystore
needs to be PrivateKeyEntry and not trustedCertEntry. Is this true? When I
look at my keystore, it is trustedCertEntry for all the certs.

But when I look at the type for the self signed certificate (which works),
it shows keyEntry.

Does, or should this matter? and if so, how do I change the type?

On Fri, Apr 4, 2014 at 4:34 PM, Mark Murphy jmarkmur...@gmail.com wrote:

1.5.0_15

On Fri, Apr 4, 2014 at 3:23 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Apr 4, 2014, at 2:52 PM, Mark Murphy jmarkmur...@gmail.com wrote:

Created my keystore according to the directions here:

http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x

Ok. Good start.

This is what I see in Chrome:

SSL Connection Error

Here is a non-SSL URL: http://www.myerstorquetracker.com
With SSL: https://www.myerstorquetracker.com

Interesting. What JVM (java -version) are you using?

Dan

I am trying to set up SSL on tomcat with a CA certificate from
goDaddy.

I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it? Please include
browser behavior and any errors / messages it gives you about the
connection.

When I try to use a self signed certificate, everything works as
expected,
but when I change the keystore to point to the one with the CA
certificate
in it, I get nothing.

What steps / instructions did you follow to generate your keystore
file?

Dan

There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

Connector protocol=org.apache.coyote.http11.Http11NioProtocol
port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=mykeystore.keystore keystorePass=
keyAlias=tcat
clientAuth=false sslProtocol=TLS /

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

On Apr 4, 2014, at 4:34 PM, Mark Murphy jmarkmur...@gmail.com wrote:

 1.5.0_15

Any chance you could try a more recent JVM?  Java 6 or preferably Java 7.  
That’s really old.

Dan

 
 On Fri, Apr 4, 2014 at 3:23 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 On Apr 4, 2014, at 2:52 PM, Mark Murphy jmarkmur...@gmail.com wrote:
 
 Created my keystore according to the directions here:
 http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x
 
 Ok.  Good start.
 
 This is what I see in Chrome:
 
 SSL Connection Error
 
 Unable to make a secure connection to the server. This may be a
 problem with the server, or it may be requiring a client
 authentication certificate that you don't have.
 Error code: ERR_SSL_PROTOCOL_ERROR
 
 Here is a non-SSL URL: http://www.myerstorquetracker.com
 With SSL: https://www.myerstorquetracker.com
 
 Interesting.  What JVM (java -version) are you using?
 
 Dan
 
 
 
 
 I am trying to set up SSL on tomcat with a CA certificate from goDaddy.
 
 I am unable to load the Web Page using HTTPS.
 
 What exactly happens when you try to access it?  Please include browser 
 behavior and any errors / messages it gives you about the connection.
 
 
 When I try to use a self signed certificate, everything works as expected,
 but when I change the keystore to point to the one with the CA certificate
 in it, I get nothing.
 
 What steps / instructions did you follow to generate your keystore file?
 
 Dan
 
 There is nothing in the log that isn't there for the
 Self-Signed startup either.
 
 Here is the Connector declaration:
 
 Connector protocol=org.apache.coyote.http11.Http11NioProtocol 
 port=443
 scheme=https secure=true SSLEnabled=true
 keystoreFile=mykeystore.keystore keystorePass= keyAlias=tcat
 clientAuth=false sslProtocol=TLS /
 
 The keystore contains tcat as one of the three keys. The other two
 entries are root and intermed from goDaddy.
 
 Where can I look to find the issue?
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

2014-04-04 Thread Mark Thomas

On 04/04/2014 21:42, Mark Murphy wrote:
 I saw something on StackOverflow that said the key type in the keystore
 needs to be PrivateKeyEntry and not trustedCertEntry. Is this true? When I
 look at my keystore, it is trustedCertEntry for all the certs.
 
 But when I look at the type for the self signed certificate (which works),
 it shows keyEntry.
 
 Does, or should this matter? and if so, how do I change the type?

Yes, this matters a lot.

You must import the cert you receive from the CA into the same keystore
you used to generate the CSR since that is where the private key is and
the server has to have access to the private key.

Mark


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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

On Apr 4, 2014, at 4:42 PM, Mark Murphy jmarkmur...@gmail.com wrote:

But when I look at the type for the self signed certificate (which works),
it shows keyEntry.

Does, or should this matter? and if so, how do I change the type?

Did you run the commands exactly as described in the link that you provided?
If not you should go through the process again and follow them exactly. You
can pretty much copy and paste them as they are listed in that document.

Dan

On Fri, Apr 4, 2014 at 4:34 PM, Mark Murphy jmarkmur...@gmail.com wrote:

1.5.0_15

On Fri, Apr 4, 2014 at 3:23 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:
On Apr 4, 2014, at 2:52 PM, Mark Murphy jmarkmur...@gmail.com wrote:

Created my keystore according to the directions here:

http://support.godaddy.com/help/article/5239/generating-a-csr-and-installing-an-ssl-certificate-in-tomcat-4x5x6x7x

Ok. Good start.

This is what I see in Chrome:

SSL Connection Error

Here is a non-SSL URL: http://www.myerstorquetracker.com
With SSL: https://www.myerstorquetracker.com

Interesting. What JVM (java -version) are you using?

Dan

I am trying to set up SSL on tomcat with a CA certificate from
goDaddy.

I am unable to load the Web Page using HTTPS.

What exactly happens when you try to access it? Please include
browser behavior and any errors / messages it gives you about the
connection.

When I try to use a self signed certificate, everything works as
expected,
but when I change the keystore to point to the one with the CA
certificate
in it, I get nothing.

What steps / instructions did you follow to generate your keystore
file?

Dan

There is nothing in the log that isn't there for the
Self-Signed startup either.

Here is the Connector declaration:

Connector protocol=org.apache.coyote.http11.Http11NioProtocol
port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=mykeystore.keystore keystorePass=
keyAlias=tcat
clientAuth=false sslProtocol=TLS /

The keystore contains tcat as one of the three keys. The other two
entries are root and intermed from goDaddy.

Where can I look to find the issue?

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

Re: apt-get tomcat7 missing websocket jars

2014-04-04 Thread Sean Winterberger

Thanks Konstantin!  Makes sense, I will switch over to manually installing
the release.

Best Regards,
Sean


On Fri, Apr 4, 2014 at 12:10 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2014-04-04 21:59 GMT+04:00 Sean Winterberger sean.winterber...@gmail.com
 :
  We just updated to tomcat 7.0.52 using the JSR356 implementation for
  websockets.  This implementation is using the annotated class method of
  setting up the websocket server endpoint.
 
  On a local install of the system (windows7) the tomcat lib directory
  contains tomcat7-websocket.jar and websocket-api.jar, however I do not
 seem
  to be getting those two files from apt-get install tomcat7.
 
  We are using Chef to deploy to multiple instances to AWS and adding the
  trust repo to apt to pull down ver 7.0.52 of Tomcat.
 
  deb http://archive.ubuntu.com/ubuntu/ trusty main
 
  We are accessing our websocket server via https, not wss since we are
 using
  AWS ELBs.
 
  After spending a few hours trying to figure out why the connections were
  returning 404 for the endpoint I realized the /usr/share/tomcat7/lib dir
  was missing the websocket jars.
 
  Is this working as intended?  Is there a separate apt pkg we can install
 to
  get the proper jars for websocket or do we have to package these jars
  ourselves?
 

 1. ASF does not provide those apt files. It is up to Debian devs how
 they pack them.

 2. It makes perfect sense to move those jars into separate package:
 1) They require Java 7
 2) They make startup slower, because of annotation scanning that is
 needed to detect WebSocket endpoints

 https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
 https://wiki.apache.org/tomcat/HowTo/FasterStartUp

 Best regards,
 Konstantin Kolinko

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

So let me try to understand what is going on here. I generate a keystore
using keytool, that contains a key. At this point it is equal to a self
signed certificate, and it works, but the browser complains that there is
no CA. I then need to create a certificate request ad send that off to
goDaddy. What is this? a public key that matches up with the private key?
Then I have to import the certificates that goDaddy returns to me because
that validates the private key that is already in the keystore?


On Fri, Apr 4, 2014 at 4:46 PM, Mark Thomas ma...@apache.org wrote:

 On 04/04/2014 21:42, Mark Murphy wrote:
  I saw something on StackOverflow that said the key type in the keystore
  needs to be PrivateKeyEntry and not trustedCertEntry. Is this true? When
 I
  look at my keystore, it is trustedCertEntry for all the certs.
 
  But when I look at the type for the self signed certificate (which
 works),
  it shows keyEntry.
 
  Does, or should this matter? and if so, how do I change the type?

 Yes, this matters a lot.

 You must import the cert you receive from the CA into the same keystore
 you used to generate the CSR since that is where the private key is and
 the server has to have access to the private key.

 Mark


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

Re: catalina.out anomaly?

2014-04-04 Thread Shanti Suresh

All,

First of all, I apologize for the question on catalina.out being empty in
v7.0.23.  That's because I am using log4j for Tomcat logging, and the level
was set to ERROR.

Here is an interesting finding between v7.0.23 and v7.0.52.  It appears
that a 3 second delay occurs in v7.0.52 as the debug logs show below for
context, lsa:

-start of v7.0.23 debug log snippet:---
[2014-04-04 14:55:37,661][DEBUG] org.apache.catalina.util.LifecycleBase -
Setting state for [WebappLoader[/lsa]] to [STARTED]
[2014-04-04 14:55:37,662][DEBUG] org.apache.catalina.startup.ContextConfig
- Context [/lsa] will parse web.xml and web-fragment.xml files with
validation:false and namespaceAware:false
[2014-04-04 14:55:37,682][DEBUG] org.apache.catalina.util.LifecycleBase -
Setting state for
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/lsa].StandardWrapper[jsp]]
to [INITIALIZING]

-end of v7.0.23 debug log snippet-

start of v7.0.52 debug log snippet:---
[2014-04-04 16:37:09,525][DEBUG] org.apache.catalina.util.LifecycleBase -
Setting state for [WebappLoader[/lsa]] to [STARTED]
[2014-04-04 16:37:09,526][DEBUG] org.apache.catalina.startup.ContextConfig
- Context [/lsa] will parse web.xml and web-fragment.xml files with
validation:false and namespaceAware:false
[2014-04-04 16:37:12,043][DEBUG] org.apache.catalina.util.LifecycleBase -
Setting state for
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/lsa].StandardWrapper[jsp]]
to [INITIALIZING]
--end of v7.0.52 debug log snippet--

So why is there such a delay in initializing a context between the two
versions?  I have noticed delays of up to 6 or 7 seconds in configuring a
context in v7.0.52.

Thanks,

   -Shanti

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

Sorry for the dumb questions, I am new to SSL, and want to understand what
I am doing, not just run these instructions, and it should work.


On Fri, Apr 4, 2014 at 5:00 PM, Mark Murphy jmarkmur...@gmail.com wrote:

 So let me try to understand what is going on here. I generate a keystore
 using keytool, that contains a key. At this point it is equal to a self
 signed certificate, and it works, but the browser complains that there is
 no CA. I then need to create a certificate request ad send that off to
 goDaddy. What is this? a public key that matches up with the private key?
 Then I have to import the certificates that goDaddy returns to me because
 that validates the private key that is already in the keystore?


 On Fri, Apr 4, 2014 at 4:46 PM, Mark Thomas ma...@apache.org wrote:

 On 04/04/2014 21:42, Mark Murphy wrote:
  I saw something on StackOverflow that said the key type in the keystore
  needs to be PrivateKeyEntry and not trustedCertEntry. Is this true?
 When I
  look at my keystore, it is trustedCertEntry for all the certs.
 
  But when I look at the type for the self signed certificate (which
 works),
  it shows keyEntry.
 
  Does, or should this matter? and if so, how do I change the type?

 Yes, this matters a lot.

 You must import the cert you receive from the CA into the same keystore
 you used to generate the CSR since that is where the private key is and
 the server has to have access to the private key.

 Mark


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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

2014-04-04 Thread Toby Lazar

Another option I normally use that may work for you (just confirmed it for
myself with tomcat):

1. Copy your private key and signed public certificate in PEM format into a
single file looking like this:

-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,F2CCC247E25D
.
.
.
-END RSA PRIVATE KEY-
-BEGIN CERTIFICATE-
.
.
-END CERTIFICATE-


2. Run portecle
3. File -- New Keystore (JKS)
4. Tools - Import Key Pair...
5. Select your file, take the defaults.  You'll need to provide the
password for your private key if you had one.
6. Save your JKS file.  Provide a password.
7. Reference it in your tomcat config.  Omit the alias.

Your server will now present just the signed public certificate but not any
others in the chain.  Once you get this working, you can update the JKS
with portecle to add intermediate certs.

HTH,

Toby


***
  Toby Lazar
  Capital Technology Group
  Email: tla...@capitaltg.com
  Mobile: 646-469-5865
***


On Fri, Apr 4, 2014 at 5:01 PM, Mark Murphy jmarkmur...@gmail.com wrote:

 Sorry for the dumb questions, I am new to SSL, and want to understand what
 I am doing, not just run these instructions, and it should work.


 On Fri, Apr 4, 2014 at 5:00 PM, Mark Murphy jmarkmur...@gmail.com wrote:

  So let me try to understand what is going on here. I generate a keystore
  using keytool, that contains a key. At this point it is equal to a self
  signed certificate, and it works, but the browser complains that there is
  no CA. I then need to create a certificate request ad send that off to
  goDaddy. What is this? a public key that matches up with the private key?
  Then I have to import the certificates that goDaddy returns to me because
  that validates the private key that is already in the keystore?
 
 
  On Fri, Apr 4, 2014 at 4:46 PM, Mark Thomas ma...@apache.org wrote:
 
  On 04/04/2014 21:42, Mark Murphy wrote:
   I saw something on StackOverflow that said the key type in the
 keystore
   needs to be PrivateKeyEntry and not trustedCertEntry. Is this true?
  When I
   look at my keystore, it is trustedCertEntry for all the certs.
  
   But when I look at the type for the self signed certificate (which
  works),
   it shows keyEntry.
  
   Does, or should this matter? and if so, how do I change the type?
 
  Yes, this matters a lot.
 
  You must import the cert you receive from the CA into the same keystore
  you used to generate the CSR since that is where the private key is and
  the server has to have access to the private key.
 
  Mark
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does

2014-04-04 Thread Mark Thomas

On 04/04/2014 22:00, Mark Murphy wrote:
 So let me try to understand what is going on here. I generate a keystore
 using keytool, that contains a key. At this point it is equal to a self
 signed certificate, and it works, but the browser complains that there is
 no CA. I then need to create a certificate request ad send that off to
 goDaddy. What is this? a public key that matches up with the private key?
 Then I have to import the certificates that goDaddy returns to me because
 that validates the private key that is already in the keystore?

You *really* need to attend my talk on SSL at ApacheCon next week. I go
through this is a lot more detail (the slides and audio recordings of
all the ApacheCon presentations should be available after the conference).

The short version is:

You generate the keystore with keytool. At this point the keystore
contains your private key and your public key.

You generate a Certificate Signing Request (CSR) which is essentially a
copy of your public key and your server's identity information (i.e. the
FQDN). You send this CSR to your chosen Certificate Authority (CA).

The CA generates a certificate for you. This certificate is essentially
your public key, your server's identify information (i.e. everything
from the CSR) plus the digital signature from the CA to confirm that
they have validated the identity information.

You import the certificate into the keystore and it replaces the public
key with the certificate (remembering that the cert is public key + id +
digital signature so you haven't lost anything).


The CA that signed your certificate might not be one of the root CAs
trusted by the user agent. Most likely it is an intermediate CA. The
root CA will have signed the intermediate CA's certificate and the
intermediate CA will have signed your certificate. In practice, there
can be several layers of intermediate CAs. What you end up with is a
trust chain from the Root CA to your certificate. To make it easier for
the browsers to validate, you need to be able to provide all of these
certificates as part of the SSL handshake. Therefore you CA will tell
you that you need to import 1 or more additional certs into your keystore.

HTH,

Mark


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

Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 1:09 PM, Jeffrey Janner wrote:
 -Original Message- From: Jeffrey Janner
 [mailto:jeffrey.jan...@polydyne.com] Sent: Friday, April 04, 2014
 12:04 PM To: 'Tomcat Users List' Subject: RE: AW: AW:
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
 -Original Message- From: Christopher Schultz
 [mailto:ch...@christopherschultz.net] Sent: Friday, April 04,
 2014 10:23 AM To: Tomcat Users List Subject: Re: AW: AW:
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Jeffrey,
 
 On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
 -Original Message- From: André Warnier
 [mailto:aw@ice-
 sa.com]
 Sent: Thursday, April 03, 2014 5:27 PM To: Tomcat Users
 List Subject: Re: AW: AW: 
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
 Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 André,
 
 On 4/3/14, 3:34 PM, André Warnier wrote:
 Alten, Jessica-Aileen wrote:
 -Ursprüngliche Nachricht- Von: André
 Warnier [mailto:a...@ice-sa.com] Gesendet:
 Donnerstag, 3. April 2014 15:36 An: Tomcat Users
 List Betreff: Re: AW: 
 tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
 Alten, Jessica-Aileen wrote:
 A bit guessing here :
 
 You have :
 worker.ajp13w.host=localhost
 and
 
 jk_open_socket::jk_connect.c (735): connect
 to 0.0.0.0:8009
 failed
 (errno=49)
 is localhost == 0.0.0.0  ?
 
 From the point of view of mod_jk/isapi, should
 it not be
 127.0.0.1 ?
 Your answer points to the right direction.
 0.0.0.0 means: any configured IPv4-Address on
 this computer, see
 
 http://serverfault.com/questions/78048/whats-the-difference-



 
betwee
 n-
 ip
 -addre ss-0-0-0-0-and-127-0-0-1
 
 In principle this is ok at first. The Ajp13
 Connector was configured in server.xml to listen
 at any IPv4 address on
 port
 8009 - which is the default setting. But the
 connector can't find any suitable
 address.
 The problem is: The new Tomcat-Connector can't
 parse worker.ajp13w.host=localhost, instead
 localhost must be
 replaced
 with 127.0.0.1, this works!
 
 In my eyes this is a big fat bug, because most
 documentation on workers use localhost.
 localhost is actually the default for
 the
 host connection directive.
 
 The new worker directive prefer_ipv6 doesn't
 change this behavior.
 
 Hi.
 
 Can you please really check this ?
 
 Open a command window on that server, and do ping
 localhost.
 It
 should tell you what it understands by localhost.
 Copy and paste the result here :
 ping localhost
 
 Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit
 32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32
 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32
 Zeit1ms TTL=128
 Antwort
 von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
 127.0.0.1: Bytes=32 Zeit1ms TTL=128
 
 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4,
 Empfangen =
 4,
 Verloren = 0 (0% Verlust), Ca. Zeitangaben in
 Millisek.:
 Minimum
 =
 0ms, Maximum = 0ms, Mittelwert = 0ms
 
 
 That /is/ bizarre.  As far as I know, to resolve
 hostnames in
 its
 configuration, mod_jk/isapi is using the OS's resolver
 library,
 the
 same as the one ping should be using. On the other
 hand, you say that if you have
 
 worker.ajp13w.host=localhost
 it doesn't work (mod_jk cannot connect to tomcat), but
 when you change this to
 
 worker.ajp13w.host=127.0.0.1
 then it works fine.
 
 Ok, another check in a command window (and I assume
 that you
 open
 this command window *on the server itself* where mod_jk
 and Tomcat are running, right ?)
 
 test :
 
 1) telnet localhost 8009
 
 2) telnet 127.0.0.1 8009
 
 Any difference between these 2 cases ?
 
 If not, then indeed it looks like a
 mod_jk/isapi_redirect 1.2.39 problem.
 
 In any case, you cannot connect to 0.0.0.0, as this
 log line would suggest :
 
 jk_open_socket::jk_connect.c (735): connect
 to 0.0.0.0:8009
 failed
 
 Could this be an interaction between IPv4 and IPv6? Try:
 
 C: nslookup localhost
 
 You might get only 127.0.0.1 or you might also get ::
 (or something equivalent). I'm not sure why it wasn't
 happening with earlier versions of mod_jk (which?).
 
 (versions : her first post mentioned the versions she was 
 comparing)
 
 I previously asked Jessica-Aileen to do a ping localhost
 on the machine, see results above.  It definitiely pings
 127.0.0.1 .. (assuming it was done on the same machine)
 
 And I don't think that nslookup uses the local resolver.
 When I'm doing that on my Windows laptop, for localhost
 it responds not found (in many more German words)
 
 C:\Dokumente und Einstellungen\awnslookup localhost
 Server: fire-see.localdomain Address:  192.168.245.253
 
 *** localhost wurde von fire-see.localdomain nicht
 gefunden: Non- existent domain
 
 On the other hand, it does this (spot the difference..):
 
 C:\Dokumente und Einstellungen\awnslookup localhost.
 Server: fire-see.localdomain Address:

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does


Mark,

On 4.4.2014 23:00, Mark Murphy wrote:

So let me try to understand what is going on here. I generate a keystore
using keytool, that contains a key. At this point it is equal to a self
signed certificate, and it works, but the browser complains that there is
no CA.


(Standard on this list is to answer below the quote.)

By using keytool -genkeypair you generate keypair -- a private key and a 
public key. Public key is stored inside self signed certificate. Both of 
them (private key and public key inside certificate) are stored in the 
keystore that may be in various formats.




I then need to create a certificate request ad send that off to
goDaddy. What is this? a public key that matches up with the private key?


It is a public key, plus information identifying server (or individual) 
packed in one message that CAs understand.




Then I have to import the certificates that goDaddy returns to me because
that validates the private key that is already in the keystore?


First of all, you must use the same keystore you used to generate 
keypair. Then, you will most probably need to import root and 
intermediate certificates first to your keystore. Then, you need to 
import server certificate, using the same keystre and the same alias you 
used to generate keypair in the first place. If you do everything right, 
that final call to keytool -importcert will replace self signed 
certificate from your keystore with a new certificate chain.


-Ognjen

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

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does


Mark,

On 4.4.2014 23:54, Mark Thomas wrote:

The CA that signed your certificate might not be one of the root CAs
trusted by the user agent. Most likely it is an intermediate CA. The
root CA will have signed the intermediate CA's certificate and the
intermediate CA will have signed your certificate. In practice, there
can be several layers of intermediate CAs. What you end up with is a
trust chain from the Root CA to your certificate. To make it easier for
the browsers to validate, you need to be able to provide all of these
certificates as part of the SSL handshake. Therefore you CA will tell
you that you need to import 1 or more additional certs into your keystore.


Few additional notes:

If root certificate is in Java system keystore then there is no need to 
import root certificate. If not, a user must import it, either in system 
keystore or user keystore.


Order of imports is important. You first need to (optionally) import 
root certificate, then intermediate certificates (if any), and server 
certificate in the end. Messing up import order may cause server serving 
incomplete certificate chain. Incomplete chain, though not recommended, 
may serve its purpose for some browsers. Other clients (like Java) will 
fail. Browsers have means to reconstruct incomplete certificate chains, 
but this shuldn't be relied upon.


-Ognjen


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

Re: Valid certificate chain failing with unable to find valid certification path to requested


Chris,

On 4.4.2014 16:27, Christopher Schultz wrote:

So they don't have a big Daddy certificate that has signed all of
their intermediate certificates? Boo. That would fix nearly everything.


Actually, having different root certificates, one for SHA-1, and one for 
SHA-2 is recommended migration practice in order to dicth all SHA-1 
certificates at some point in time, for security reasons.




FTR, GoDaddy or any other CA can't just add certificate to Java
root certificates, but it must apply at Oracle for inclusion.


If the problem is that the client trusts GoDaddy's ROOT certificate
and the server's certificate was signed by GoDaddy's intermediate
certificate (which should have been in turn signed by the ROOT
certificate), then the solution is to include the intermediate
certificate (or certificates... some CAs have longer chains) in your
keystore and configure Tomcat to serve both the server's cert and the
intermediate cert.


Configuration for JSSE connectors is somewhat different than APR. For 
JSSE, you don't configure Tomcat to serve intermediate certificates, but 
you import them to your keystore before you import server certificate. 
By doing so, JSSE will serve the complete certificate chain to the client.





This is what I think is the relevant part: [3]: ObjectId:
2.5.29.19 Criticality=true BasicConstraints:[ CA:false
PathLen:2147483647 ]


It just says that server certificate you have cannot be used to
sign other certificates, nothing else. That is irrelevant for you.


Depending upon where this came from (there was no context given), you
are correct. If this is information from the GoDaddy certificate, then
it's likely an intermediate certificate and not a root cert.


x.509v3 Basic Constraints CA:true means that the certificate may sign 
other certificates. It would be impossible that GoDaddy signing 
certificate (either root or intermediate) have CA set to false. 
Therefore I assumed the information is about server certificate.


-Ognjen


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

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-04 Thread Martin Gainty

 From: jeffrey.jan...@polydyne.com
 To: users@tomcat.apache.org
 Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 Date: Fri, 4 Apr 2014 17:33:08 +

  -Original Message-
  From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
  Sent: Friday, April 04, 2014 12:10 PM
  To: 'Tomcat Users List'
  Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
  not work

   -Original Message-
   From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
   Sent: Friday, April 04, 2014 12:04 PM
   To: 'Tomcat Users List'
   Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
   not work

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, April 04, 2014 10:23 AM
To: Tomcat Users List
Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
does not work

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
 -Original Message- From: André Warnier [mailto:aw@ice-
sa.com]
 Sent: Thursday, April 03, 2014 5:27 PM To:
 Tomcat Users List Subject: Re: AW: AW:
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

 André,

 On 4/3/14, 3:34 PM, André Warnier wrote:
 Alten, Jessica-Aileen wrote:
 -Ursprüngliche Nachricht- Von: André Warnier
 [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
 2014 15:36 An: Tomcat Users List Betreff: Re: AW:
 tomcat-connectors-1.2.39-windows-x86_64-iis does not work

 Alten, Jessica-Aileen wrote:
 A bit guessing here :

 You have :
 worker.ajp13w.host=localhost
 and

 jk_open_socket::jk_connect.c (735): connect to
 0.0.0.0:8009
 failed
 (errno=49)
 is localhost == 0.0.0.0  ?

 From the point of view of mod_jk/isapi, should it not be
 127.0.0.1 ?
 Your answer points to the right direction. 0.0.0.0
 means: any configured IPv4-Address on this computer, see

 http://serverfault.com/questions/78048/whats-the-
  difference-

betwee
 n-
 ip
 -addre ss-0-0-0-0-and-127-0-0-1

 In principle this is ok at first. The Ajp13 Connector was
 configured in server.xml to listen at any IPv4 address on
   port
 8009 - which is the default setting.
 But the connector can't find any suitable
 address.
 The problem is: The new Tomcat-Connector can't parse
 worker.ajp13w.host=localhost, instead localhost must be
 replaced
 with 127.0.0.1, this works!

 In my eyes this is a big fat bug, because most
  documentation
 on workers use localhost. localhost is actually the
 default for
 the
 host connection directive.

 The new worker directive prefer_ipv6 doesn't change this
 behavior.

 Hi.

 Can you please really check this ?

 Open a command window on that server, and do ping
  localhost.
It
 should tell you what it understands by localhost. Copy and
 paste the result here :
 ping localhost

 Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32
  Bytes
 Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
 TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
   Antwort
 von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
  127.0.0.1:
 Bytes=32 Zeit1ms TTL=128

 Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen
 =
4,
 Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
   Minimum
=
 0ms, Maximum = 0ms, Mittelwert = 0ms

 That /is/ bizarre.  As far as I know, to resolve hostnames in
   its
 configuration, mod_jk/isapi is using the OS's resolver
  library,
the
 same as the one ping should be using. On the other hand, you
 say that if you have

 worker.ajp13w.host=localhost
 it doesn't work (mod_jk cannot connect to tomcat), but when
  you
 change this to

 worker.ajp13w.host=127.0.0.1
 then it works fine.

 Ok, another check in a command window (and I assume that you
   open
 this command window *on the server itself* where mod_jk and
 Tomcat are running, right ?)

 test :

 1) telnet localhost 8009

 2) telnet 127.0.0.1 8009

 Any difference between these 2 cases ?

 If not, then indeed it looks like a mod_jk/isapi_redirect
 1.2.39 problem.

 In any case, you cannot connect to 0.0.0.0, as this log line
 would suggest :

 jk_open_socket::jk_connect.c (735): connect to
 0.0.0.0:8009
 failed

 Could this be an interaction between IPv4 and IPv6? Try:

 C: nslookup localhost

 You might get only 127.0.0.1 or you might also get :: (or
 something equivalent).

Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-04 Thread Terence M. Bandoian


On 4/4/2014 5:52 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 1:09 PM, Jeffrey Janner wrote:

-Original Message- From: Jeffrey Janner
[mailto:jeffrey.jan...@polydyne.com] Sent: Friday, April 04, 2014
12:04 PM To: 'Tomcat Users List' Subject: RE: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work


-Original Message- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Friday, April 04,
2014 10:23 AM To: Tomcat Users List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Jeffrey,

On 4/4/14, 10:50 AM, Jeffrey Janner wrote:

-Original Message- From: André Warnier
[mailto:aw@ice-

sa.com]

Sent: Thursday, April 03, 2014 5:27 PM To: Tomcat Users
List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

André,

On 4/3/14, 3:34 PM, André Warnier wrote:

Alten, Jessica-Aileen wrote:

-Ursprüngliche Nachricht- Von: André
Warnier [mailto:a...@ice-sa.com] Gesendet:
Donnerstag, 3. April 2014 15:36 An: Tomcat Users
List Betreff: Re: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does
not work

Alten, Jessica-Aileen wrote:

A bit guessing here :

You have :

worker.ajp13w.host=localhost

and


jk_open_socket::jk_connect.c (735): connect
to 0.0.0.0:8009

failed

(errno=49)

is localhost == 0.0.0.0  ?

 From the point of view of mod_jk/isapi, should
it not be

127.0.0.1 ?

Your answer points to the right direction.
0.0.0.0 means: any configured IPv4-Address on
this computer, see

http://serverfault.com/questions/78048/whats-the-difference-

betwee

n-

ip

-addre ss-0-0-0-0-and-127-0-0-1

In principle this is ok at first. The Ajp13
Connector was configured in server.xml to listen
at any IPv4 address on

port

8009 - which is the default setting. But the
connector can't find any suitable

address.

The problem is: The new Tomcat-Connector can't
parse worker.ajp13w.host=localhost, instead
localhost must be

replaced

with 127.0.0.1, this works!

In my eyes this is a big fat bug, because most
documentation on workers use localhost.
localhost is actually the default for

the

host connection directive.

The new worker directive prefer_ipv6 doesn't
change this behavior.


Hi.

Can you please really check this ?

Open a command window on that server, and do ping
localhost.

It

should tell you what it understands by localhost.
Copy and paste the result here :

ping localhost

Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit
32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32
Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32
Zeit1ms TTL=128

Antwort

von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
127.0.0.1: Bytes=32 Zeit1ms TTL=128

Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4,
Empfangen =

4,

Verloren = 0 (0% Verlust), Ca. Zeitangaben in
Millisek.:

Minimum

=

0ms, Maximum = 0ms, Mittelwert = 0ms



That /is/ bizarre.  As far as I know, to resolve
hostnames in

its

configuration, mod_jk/isapi is using the OS's resolver
library,

the

same as the one ping should be using. On the other
hand, you say that if you have


worker.ajp13w.host=localhost

it doesn't work (mod_jk cannot connect to tomcat), but
when you change this to


worker.ajp13w.host=127.0.0.1

then it works fine.

Ok, another check in a command window (and I assume
that you

open

this command window *on the server itself* where mod_jk
and Tomcat are running, right ?)

test :

1) telnet localhost 8009

2) telnet 127.0.0.1 8009

Any difference between these 2 cases ?

If not, then indeed it looks like a
mod_jk/isapi_redirect 1.2.39 problem.

In any case, you cannot connect to 0.0.0.0, as this
log line would suggest :


jk_open_socket::jk_connect.c (735): connect
to 0.0.0.0:8009

failed

Could this be an interaction between IPv4 and IPv6? Try:

C: nslookup localhost

You might get only 127.0.0.1 or you might also get ::
(or something equivalent). I'm not sure why it wasn't
happening with earlier versions of mod_jk (which?).


(versions : her first post mentioned the versions she was
comparing)

I previously asked Jessica-Aileen to do a ping localhost
on the machine, see results above.  It definitiely pings
127.0.0.1 .. (assuming it was done on the same machine)

And I don't think that nslookup uses the local resolver.
When I'm doing that on my Windows laptop, for localhost
it responds not found (in many more German words)

C:\Dokumente und Einstellungen\awnslookup localhost
Server: fire-see.localdomain Address:  192.168.245.253

*** localhost wurde von fire-see.localdomain nicht
gefunden: Non- existent domain

On the other hand, it does this (spot the difference..):

C:\Dokumente und Einstellungen\awnslookup localhost.
Server: fire-see.localdomain Address:  192.168.245.253

Name:localhost Address:  127.0.0.1

(But that of course could be the

Re: Tomcat 6 SSL CA Certificate does not work, but Self signed Certificate does