date:20140521

Re: AJP protocol with Apache Tomcat Version 7.0.52

2014-05-21 Thread ravishankar_d

Hi Dan,

We are using apache web server provided along with RHEL.So I believe we are
getting back port fixes.
In the threaddump we are seeing the below long running threads many times.As
mentioned, we are using AJP(with BIO) and tomacat 7.0.52. I wanted to know
if this will cause any issues like system hung over a period of time. Also
we are thinking of NIO protocol instead of BIO for AJP


ajp-bio-10.181.42.51-9011-exec-112 daemon prio=10 tid=0x161aa000
nid=0x776c runnable [0x2b23c3c64000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:309)
at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:364)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:121)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:313)
- locked 0x0007b25a5b58 (a 
org.apache.tomcat.util.net.SocketWrapper)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

   Locked ownable synchronizers:
- 0x0007b25e7618 (a 
java.util.concurrent.ThreadPoolExecutor$Worker)

Regards,
Ravi





--
View this message in context: 
http://tomcat.10.x6.nabble.com/AJP-protocol-with-Apache-Tomcat-Version-7-0-52-tp5017650p5017727.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Tomcat 7 cannot get ciphers with SHA256 or SHA384

2014-05-21 Thread Sverre Moe

I installed Tomcat-7 7.0.42 in OpenSUSE 13.1, configured support for
TLSv1.2. I then configured a list of strong ciphers only, that I wanted to
use.

Connector port=8443
protocol=org.apache.coyote.http11.Http11NioProtocol maxThreads=150
clientAuth=false SSLEnabled=true scheme=https secure=true
sslProtocol=TLSv1.2 sslEnabledProtocols=TLSv1.2 keyAlias=tomcat
keystoreFile=/usr/share/tomcat/.keystore keystorePass=**
keystoreType=JKS
ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA265,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256
/

I have tried running Tomcat with Java 7 and Java 8. Both of these should
support CBC_SHA256 and CBC_SHA384, but only Java 8 supports GCM_SHA384.
I have downloaded the Java cryptographic extensions policy files for both
Java 7 and Java 8.

The only way I get a connection is when I add the following ciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

According to the specification all these ciphers are correct names:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites

According to the implementation in JSSE provider they are implemented as
well to work with TLSv1.2
http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
Footnote 1(Java7) Cipher suites with SHA384 and SHA256 are available only
for TLS 1.2 or later.


Also how come SSLLabs SSLTest tells me I do not have forward secrecy and
are using RC4 ciphers. Thought when I set a limited list of ciphers only
those can be used.

I tried to edit /usr/sbin/tomcat-sysd (which is started by service tomcat)
to enable SSL debugging, but nothing shows up in the log files
exec ${JAVACMD} $JAVA_OPTS $CATALINA_OPTS \
-classpath $CLASSPATH \
-Dcatalina.base=$CATALINA_BASE \
-Dcatalina.home=$CATALINA_HOME \
-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS \
-Djava.io.tmpdir=$CATALINA_TMPDIR ${DSECURITY_MANAGER} \

-Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.properties \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
\
-Djavax.net.debug=ssl \
org.apache.catalina.startup.Bootstrap start

tomcat6 context path attribute

2014-05-21 Thread philippe rouxel

Hello,

I have a war app-0.0.1 with a context.xml in META-INF :

?xml version=1.0?
!DOCTYPE Context
Context path=/app
/Context

When I deploy it, in CATALINA_BASE\conf\Catalina\localhost a file
app-0.0.1.xml is created.

When I call
 localhost:8080/app I got 404
 localhost:8080/app-0.0.1 I got 200

I have try
?xml version=1.0?
!DOCTYPE Context
Context path=/app docBase=../webapps/app-0.0.1.war
/Context
with the same result

Did i miss nothing?

I using tomcat 6.0.39

Regards

Re: tomcat6 context path attribute

2014-05-21 Thread Konstantin Kolinko

2014-05-21 15:05 GMT+04:00 philippe rouxel prouxel.pa...@gmail.com:
 Hello,

 I have a war app-0.0.1 with a context.xml in META-INF :

 ?xml version=1.0?
 !DOCTYPE Context
 Context path=/app
 /Context

 When I deploy it, in CATALINA_BASE\conf\Catalina\localhost a file
 app-0.0.1.xml is created.

 When I call
  localhost:8080/app I got 404
  localhost:8080/app-0.0.1 I got 200

 I have try
 ?xml version=1.0?
 !DOCTYPE Context
 Context path=/app docBase=../webapps/app-0.0.1.war
 /Context
 with the same result

 Did i miss nothing?

 I using tomcat 6.0.39

Read Configuration Reference Guide. The path attribute is described there.
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

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

Re: Why is my Tomcat connection getting terminated/closed?!!

2014-05-21 Thread Aniket Bhoi

On Tue, May 20, 2014 at 5:28 PM, Daniel Mikusa dmik...@gopivotal.comwrote:

On May 20, 2014, at 7:47 AM, Aniket Bhoi aniket.b...@gmail.com wrote:

It has been working perfectly fine thus far.As far as i have analysed
there
have been no changes to the firewall or database settings.I will however
try and implement your suggestion to setup a validation query.

1.) Don’t top post. Reply inline, like this, or at the bottom. This is
the convention we follow on this list.

2.) The fact that you have not recently changed your firewall or database
settings doesn’t really mean much. The problem may have not happened
before because it just didn’t get triggered. From the db / firewall side,
what commonly causes this is a timeout. The connection is open and idle
for too long and either the DB server or firewall disconnects it. Perhaps
the connections just haven’t idled long enough until now.

3.) It’s generally good practice to have a validation query / testOnBorrow
(or one of the other tests) enabled. If you didn’t have this before, you
should consider adding it regardless of the problem. It can help with
other things too.

Dan

I checked the code and the server settings,and We already have
validation query and testOnBorrow in place.We found out from our data
management team,that there have been many sleeping connections from the
tomcat servers to the database.

Sleeping threads =
http://dinesql.blogspot.in/2010/07/sql-server-sleeping-status-and.html

We got those connection threads killed just to make sure there the
connection pool limit isnt breached.However even after cleaning up those
connection threads to the DB ,we still gett the same exception.

Aniket

On Tue, May 20, 2014 at 5:12 PM, Daniel Mikusa dmik...@gopivotal.com
wrote:

On May 20, 2014, at 7:35 AM, Aniket Bhoi aniket.b...@gmail.com wrote:

I have Apache Solr,hosted on my apache Tomcat Server

Details:

Tomcat version:
Apache Tomcat/6.0.18

This is really, really old. You should upgrade.

OS details
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1

While running indexing on this server,It failed.

Log excerpt:
SEVERE: Can not close connection
java.sql.SQLException: Already closed.

Hard to say why this is happening (database server setting, firewall,
bad
code, etc.) but something is closing the connection and not telling the
pool. You can work around this by setting a validation query on your
connection pool and enabling “testOnBorrow”. That will instruct the
pool
to check connections before they are given out. Bad connections will be
closed and replaced, if needed.

Dan

org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:84)
at

org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:189)
at

org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.closeResources(Unknown
Source)
at

org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(Unknown
Source)
at

org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.access$500(Unknown
Source)
at

org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(Unknown
Source)
at
org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(Unknown
Source)
at
org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(Unknown
Source)
at

org.apache.solr.handler.dataimport.ThreadedEntityProcessorWrapper.nextRow(Unknown
Source)
at

org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.runAThread(Unknown
Source)
at

org.apache.solr.handler.dataimport.DocBuilder$EntityRunner.access$000(Unknown
Source)
at

org.apache.solr.handler.dataimport.DocBuilder$EntityRunner$1.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)

I suspect this to be an issue with the tomcat connection thread to the
database being terminated/timed out.

Need help as to why this is happening!.

Regards

Aniket

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

Re: Why is my Tomcat connection getting terminated/closed?!!

2014-05-21 Thread Jose María Zaragoza

2014-05-21 13:28 GMT+02:00 Aniket Bhoi aniket.b...@gmail.com:
On Tue, May 20, 2014 at 5:28 PM, Daniel Mikusa dmik...@gopivotal.comwrote:

On May 20, 2014, at 7:47 AM, Aniket Bhoi aniket.b...@gmail.com wrote:

1.) Don’t top post. Reply inline, like this, or at the bottom. This is
the convention we follow on this list.

Dan

Sleeping threads =
http://dinesql.blogspot.in/2010/07/sql-server-sleeping-status-and.html

Aniket

Another option is to set testOnReturn=true.
As your problem is closing connections already closed ,test them
before returning them to pool.
Maybe it works.