date:20140305

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/5/14, 3:32 AM, Mark Thomas wrote:
 On 05/03/2014 01:50, Christopher Schultz wrote:
 
 snip/
 
 When I run under Tomcat 8.0.3, a couple of the images are
 loaded, and then the whole ... thing ... just ... stops. If I
 watch my log4j log file, every so often a flurry of activity
 occurs: several pieces of information are actually fetched from
 the database, and progress is made. But I have waited like 10
 minutes and the series of requests never finishes in that time.
 
 I'd suggest compiling 8.0.x from trunk as that is now using the 
 released DBCP 2.0 and Pool 2.2. There was a pool issue (POOL-248)
 that was fixed after the 8.0.x release that might have caused
 this.

I was thinking about that last night. I also saw the commit that
upgrades to the DBCP2 release version, which was what really triggered
that thought. Can you point me to the JIRA issue you were specifically
thinking could be what I'm encountering?

 (Something odd I can see: when that small amount of progress is 
 made, the idle connection in MySQL *remains* idle. The only 
 conclusion I can come to is that a new connection is being
 created to fetch that data and then it's being dropped, or that
 something is giving up somewhere without telling me. Neither
 conclusion makes much sense. I haven't actually confirmed that
 any real progress is made... just that I can see loading XYZ
 from db in my log files... those messages are logged *before*
 the data is loaded so I don't know it has been at this point).
 
 Take a look at the pool with JMX. Again, if you work with trunk
 you'll get lots of detail of exactly what each connection is
 doing.

I'll do that.

 
 Thread dumps show that everything is waiting on:
 
 - org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection() 
 @bci=55, line=1385 (Interpreted frame)
 
 It's not that large a number of threads. It's something like
 30-40 threads waiting on connections. (I'm not entirely sure why
 there are so many threads active... I'm the only one using this 
 environment and I made a single top-level request... I thought
 most browsers limited their outgoing connections to something
 like 8 per hostname, but that appears not to be the case).
 
 While that doesn't rule out a DBCP issuee, it does suggest that
 there is at least something else going on that you need to get to
 the bottom of.

I need to re-run the test again, but I have a new theory after
watching nothing but the log files and the number of stuck-threads in
jstack on my previous run: Firefox is giving-up on the connections
that never returned any data and closes them, making new requests to
take their place.

My evidence is that when the primary request completes (that's the
one that generates the HTML page that requires follow-up resources),
only a few threads get stuck (immediately). After some time interval
(exactly 5 minutes), I get another flurry of Loading data lines in
my log file and another set of threads gets stuck waiting on a connection.

 My DataSource configuration:
 
 Resource name=jdbc/diagnosis description=JDBC connection to 
 main CHADIS database auth=Container
 type=javax.sql.DataSource maxActive=1 maxIdle=1
 maxWait=1 url=[url] username=[user] password=[user] 
 driverClassName=com.mysql.jdbc.Driver removeAbandoned=true 
 removeAbandonedTimeout=30 logAbandoned=true 
 testOnBorrow=true validationQuery=/* ping */ SELECT 1 /
 
 Note that I have a single database connection in the pool.
 
 Not with DBCP 2 you don't. maxActive has been renamed to maxTotal
 so you'll have the default (8 from memory) connections in the pool.
 This is likely to be a common problem. We probably need to add
 something to catch this, report a warning and set the correct
 attribute.

Okay, I'll take a look at that. What I can observe practically is that
only a single connection to my MySQL database has been made, whatever
the reason. Perhaps that's part of the trouble.

 You can also drop the validationQuery. DBCP2 will use isValid()
 which is just as fast and frequently faster.

Okay. For my remaining tests, I'll leave things alone.

(Why would isValid be better? Is it because the driver itself can
determine the fastest way to test the connection's validity? For
MySQL, the /* ping */ in the validationQuery gets the job done without
issuing the query at all, which is nice.)

 It looks like DBCP2 is kind of hosing, here.
 
 I don't have a simple test case right now, unfortunately, but I
 do know that it has worked every time (maybe a dozen times)
 under Tomcat 7.0.47 and failed every time (maybe 5 times, now)
 under Tomcat 8.0.3.
 
 I'm going to try using tomcat-pool to see if it makes any 
 difference. I suspect it will, since they are completely
 different architectures.=
 
 Any suggestions?
 
 - Fix the config

I'll try this first just to see if it helps. I suspect not, as I was
only seeing a single connection, anyway. I'll let you know.

 - Switch to a trunk build

I'll

Re: Stream closed- IOException exception

2014-03-05 Thread Prashant Kadam

On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Prashant,

 On 3/3/14, 6:04 AM, Prashant Kadam wrote:
  please help ... I have removed whitespaces by adding jsp-config
  jsp-property-group url-pattern*.jsp/url-pattern
  trim-directive-whitespacestrue/trim-directive-whitespaces
  /jsp-property-group /jsp-config but still i am facing same
  error.

 This may or may not do anything.

  I tried to increase the buffer size also as, %@ page
  buffer=800kb autoFlush=false % but still same error

 Hm. With a huge buffer, the only reason the response would have been
 committed is if a flush() was being called somewhere. You said you
 gutted the struts actions, but it's possible that somewhere, Struts is
 internally flushing the buffer. (That would surprise me, honestly).
 Are you sure there are no errors occurring anywhere? Often, an error
 will cause the response to be committed.

 BTW you probably never want to use autoFlush=false unless you are
 watching the buffer very carefully. For debugging, it's fine, but you
 certainly don't want to do that on a regular basis.

  stuck on this issue for more than 2 weeks now and need to close it
  ASAP please help.

 Remember that this is a community made up of volunteers. This problem
 / ticket is *yours* and not ours to be solved ASAP. Everybody's issues
 need to be solved ASAP, of course. If you want something done ASAP and
 you can't do it yourself, then you'll have to pay someone else to do it.

  Any help/ pointer would be highly appreciated.
 
  one more things, we are using struts version 1 and tiles 2.2. as
  struts1 doesn't work with tiles2, we have used
  struts-tiles2-1.4.0-SNAPSHOT.jar, can this create any problem, but
  this combination work with tomcat version below 7.0.37 and giving
  issues from version 7.0.39.
 
  Can anybody please tell me what are the changes in between these
  two versions which can produce this errror ??

 You could take a look at the Changelog for version 7.0.39 (or .38) to
 see if anything looks probable. I recommend using a debugger as
 Konstantin suggests and trap the condition. You'll be able to unwind
 the stack to see what code is causing the response to be committed.



hi Thanks for your reply.
I started debugging the code and found some pointers but not able to fully
identify the root cause.
What I found is,

In TilesRequestProcessor class

   protected void doForward(
String uri,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {

if (response.isCommitted()) {
this.doInclude(uri, request, response);

} else {
super.doForward(uri, request, response);
}
}

with version 7.0.39, somewhere
org.apache.jasper.runtime.ServletResponseWrapperInclude.*isCommited* is
setting to false, causing forward but response is already commited and
throws IO Exception.
with version 7.0.37, particularly for this request this flag sets to true
and it works.

any pointers on this ? how can I find from where this is setting to false ?



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

 iQIcBAEBCAAGBQJTFLrqAAoJEBzwKT+lPKRYYx0P/jQ065OqO2xG+TiWv8Nkyht8
 HMewLURHezpCkWM3Q2tCrV4mgTXLgvs1eOMBdi4LTjvzAdLjPNRBBQhR0bXjjIIS
 gAu92exfyuoBgN8mkgBTgZpmIFa/xPIbj+xDdImFHYcpHCrRw7ga4V9iyum27UQF
 JkXGz/qOegMattgF2k6Dgkz2UBN7QLwqnAqpaFo3m9XNqc6eQdTQWTzZ+MXX2tJ2
 dndK+Bu+sdlWDeCtnegGO8ieh5GH0SB67ygSnBC/FPQOTDKojTpG7XbvrKonviUH
 2u8S1gBuRClGGWXYv73LTCIYM5hpZA6S86nHD8UBciNTEx/rfLFtDGfpyb0lSVo8
 4/kt/XIuqzmnrFkV2+Do2/xmorAs3QADlkmaK1e0cT1yVCBGUwU1FfalELj6JICj
 Wc73VB2SPDgwnY8qS1haa8V+LHZq4KVj9M1ZVf1buA7sFQTHeMsezP7KMmySJ6GU
 Ht70ubSvCIiEiSKT/gBeRcaTr1G6tyD4mObrKoz87BDMJbfe5yfkhguDKa3xvZLa
 +4oVvROVYklE1ZVAvY4IUH+LHTpWIL9HJFtWxi2C+KE0ihs8wq+iA+KMdkwB4W7H
 9l231PiUE8ugya9K6qvDglPXhB5TvzIqpRoyb3lomESTwYuqDERYGRs3ouIVuJ3f
 vF1I9tIciTVKPwzRNESN
 =ukUm
 -END PGP SIGNATURE-

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




-- 
~ Prashant Kadam

Re: Performance drop under load for Tomcat8/DBCP2 with respect to Tomcat 7/DBCP1

2014-03-05 Thread Mark Thomas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/03/2014 13:38, Christopher Schultz wrote:
 Mark,
 
 On 3/5/14, 3:32 AM, Mark Thomas wrote:
 On 05/03/2014 01:50, Christopher Schultz wrote:
 
 snip/
 
 When I run under Tomcat 8.0.3, a couple of the images are 
 loaded, and then the whole ... thing ... just ... stops. If I 
 watch my log4j log file, every so often a flurry of activity 
 occurs: several pieces of information are actually fetched
 from the database, and progress is made. But I have waited like
 10 minutes and the series of requests never finishes in that
 time.
 
 I'd suggest compiling 8.0.x from trunk as that is now using the 
 released DBCP 2.0 and Pool 2.2. There was a pool issue
 (POOL-248) that was fixed after the 8.0.x release that might have
 caused this.
 
 I was thinking about that last night. I also saw the commit that 
 upgrades to the DBCP2 release version, which was what really
 triggered that thought. Can you point me to the JIRA issue you were
 specifically thinking could be what I'm encountering?

POOL-248.

 (Something odd I can see: when that small amount of progress is
  made, the idle connection in MySQL *remains* idle. The only 
 conclusion I can come to is that a new connection is being 
 created to fetch that data and then it's being dropped, or
 that something is giving up somewhere without telling me.
 Neither conclusion makes much sense. I haven't actually
 confirmed that any real progress is made... just that I can see
 loading XYZ from db in my log files... those messages are
 logged *before* the data is loaded so I don't know it has been
 at this point).
 
 Take a look at the pool with JMX. Again, if you work with trunk 
 you'll get lots of detail of exactly what each connection is 
 doing.
 
 I'll do that.
 
 
 Thread dumps show that everything is waiting on:
 
 - org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection()
  @bci=55, line=1385 (Interpreted frame)
 
 It's not that large a number of threads. It's something like 
 30-40 threads waiting on connections. (I'm not entirely sure
 why there are so many threads active... I'm the only one using
 this environment and I made a single top-level request... I
 thought most browsers limited their outgoing connections to
 something like 8 per hostname, but that appears not to be the
 case).
 
 While that doesn't rule out a DBCP issuee, it does suggest that 
 there is at least something else going on that you need to get
 to the bottom of.
 
 I need to re-run the test again, but I have a new theory after 
 watching nothing but the log files and the number of stuck-threads
 in jstack on my previous run: Firefox is giving-up on the
 connections that never returned any data and closes them, making
 new requests to take their place.
 
 My evidence is that when the primary request completes (that's
 the one that generates the HTML page that requires follow-up
 resources), only a few threads get stuck (immediately). After some
 time interval (exactly 5 minutes), I get another flurry of Loading
 data lines in my log file and another set of threads gets stuck
 waiting on a connection.
 
 My DataSource configuration:
 
 Resource name=jdbc/diagnosis description=JDBC connection to
  main CHADIS database auth=Container 
 type=javax.sql.DataSource maxActive=1 maxIdle=1 
 maxWait=1 url=[url] username=[user] password=[user]
  driverClassName=com.mysql.jdbc.Driver removeAbandoned=true
  removeAbandonedTimeout=30 logAbandoned=true 
 testOnBorrow=true validationQuery=/* ping */ SELECT 1 /
 
 Note that I have a single database connection in the pool.
 
 Not with DBCP 2 you don't. maxActive has been renamed to
 maxTotal so you'll have the default (8 from memory) connections
 in the pool. This is likely to be a common problem. We probably
 need to add something to catch this, report a warning and set the
 correct attribute.
 
 Okay, I'll take a look at that. What I can observe practically is
 that only a single connection to my MySQL database has been made,
 whatever the reason. Perhaps that's part of the trouble.

Hmm. I don't recall exactly when this was renamed in DBCP 2. It is
always possible the build you are using does what you think it does.

 You can also drop the validationQuery. DBCP2 will use isValid() 
 which is just as fast and frequently faster.
 
 Okay. For my remaining tests, I'll leave things alone.
 
 (Why would isValid be better? Is it because the driver itself can 
 determine the fastest way to test the connection's validity?

Yes.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTFy0NAAoJEBDAHFovYFnnAwsQAPeHLWrK5Q8uANmrxqau+9/y
rLkiODMTXPDvQbqod2AavqKKX+uLGQzyEI2mw4svuE+rca0Q37TfXNGsfK9F6u3x
NzJl91VaXOyT/3fuHfGeYHWmwdM1uT1QrK8ISRmf0eZEN9YSqk96rPnx/iB1UvYz
lxCbzndn5qVxwz/t1gMhW9WYTYGNQpMnFUtMt+G1m/yQ+uSs0kN1v5Ns6ppK8Q3S
RizQYWrUr8P1K/IsmuVnWOBLuNJJxaufGa3C3T6qFumGSDibiTgR/NwMeVpZ3JIa

RE: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

2014-03-05 Thread Martin Gainty

FYI If you are using NIO Connector you will want to supply these NIO Connector 
attributes

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

 

If you are using SSL on NIO read SSL on NIO for that capability

 

APR Native SSL would use these parameters






Attribute
Description

SSLCACertificateFile

See the mod_ssl documentation.


SSLCACertificatePath

See the mod_ssl documentation.


SSLCARevocationFile

See the mod_ssl documentation.


SSLCARevocationPath

See the mod_ssl documentation.


SSLCertificateChainFile

See the mod_ssl documentation.


SSLCACertificateFile

Name of the file that contains the concatenated certificates for the trusted 
certificate authorities. The format is PEM-encoded.


SSLCACertificatePath

Name of the directory that contains the certificates for the trusted 
certificate authorities. The format is PEM-encoded.


SSLCARevocationFile

Name of the file that contains the concatenated certificate revocation lists 
for the certificate authorities. The format is PEM-encoded.


SSLCARevocationPath

Name of the directory that contains the certificate revocation lists for the 
certificate authorities. The format is PEM-encoded.


SSLCertificateChainFile

Name of the file that contains concatenated certifcates for the certificate 
authorities which form the certifcate chain for the server certificate. The 
format is PEM-encoded.


SSLCertificateFile

Name of the file that contains the server certificate. The format is 
PEM-encoded.


SSLCertificateKeyFile

Name of the file that contains the server private key. The format is 
PEM-encoded. The default value is the value of SSLCertificateFile and in this 
case both certificate and private key have to be in this file (NOT RECOMMENDED).


SSLCipherSuite

Ciphers which may be used for communicating with clients. The default is ALL, 
with other acceptable values being a list of ciphers, with : used as the 
delimiter (see OpenSSL documentation for the list of ciphers supported).


SSLDisableCompression

Disables compression if set to true and OpenSSL supports disabling compression. 
Default is false which inherits the default compression setting in OpenSSL.


SSLHonorCipherOrder

Set to true to enforce the server's cipher order (from the SSLCipherSuite 
setting) instead of allowing the client to choose the cipher (which is the 
default).


SSLPassword

Pass phrase for the encrypted private key. If SSLPassword is not provided, 
the callback function should prompt for the pass phrase.


SSLProtocol

Protocol which may be used for communicating with clients. The default value is 
all, which is equivalent to SSLv3+TLSv1 with other acceptable values being 
SSLv2, SSLv3, TLSv1 and any combination of the three protocols concatenated 
with a plus sign. Note that the protocol SSLv2 is inherently unsafe.


SSLVerifyClient

Ask client for certificate. The default is none, meaning the client will not 
have the opportunity to submit a certificate. Other acceptable values include 
optional, require and optionalNoCA.


SSLVerifyDepth

Maximum verification depth for client certificates. The default is 10.

 

Tweak these Connector timeout parameters to acomodate your requirement

asyncTimeout

connectionTimeout

connectionUploadTimeout

disableUploadTimeout

executorTerminationTimeoutMillis

keepAliveTimeout

socket.soTimeout

socket.unlockTimeout

selectorTimeout
sessionTimeout


(yes..Mr Schultz is correct on the last statement)
Martin-

  



 Date: Wed, 5 Mar 2014 15:12:02 +0200
 Subject: Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: 
 Assertion failed
 From: dmitry.batiyevs...@ardas.dp.ua
 To: users@tomcat.apache.org
 
 Atmosphere upgrade didn't help
 
 Regards,
 
 Dmitry Batiyevskiy
 
 Ardas Group Inc.
 
 www.ardas.dp.ua
 
 
 2014-03-05 9:39 GMT+02:00 Dmitry Batiyevskiy dmitry.batiyevs...@ardas.dp.ua
 :
 
  We are ok with tomcat 7.0.42 and old tcnative now, and may be next
  tcnative update will work appropriately
  We will try updating atmosphere before trying NIO anyway
 
  Regards,
 
  Dmitry Batiyevskiy
 
  Ardas Group Inc.
 
  www.ardas.dp.ua
 
 
  2014-03-04 23:18 GMT+02:00 Christopher Schultz 
  ch...@christopherschultz.net:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Dmitry,
 
  On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote:
   Howard, My connector config is the following (i've already posted
   that):
  
   Connector port=8443 maxHttpHeaderSize=8192 maxThreads=15000
   enableLookups=false disableUploadTimeout=true acceptCount=100
   scheme=https secure=true SSLEnabled=true compression=off
   SSLCertificateFile=/opt/tomcat/mycompany.com.crt
   SSLCertificateKeyFile=/opt/tomcat/mycompany.com.key /
  
   Also -Dhttps.protocols=TLSv1 option is passed to java machine
  
   The reason for me to use apr connector is https performance, isn't
   NIO much slower in that?
 
  I don't have any recent performance data, but using OpenSSL is
  apparently measurably faster than using

Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

2014-03-05 Thread Dmitry Batiyevskiy

Thanks

Regards,

Dmitry Batiyevskiy

Ardas Group Inc.

www.ardas.dp.ua


2014-03-05 16:04 GMT+02:00 Martin Gainty mgai...@hotmail.com:

 FYI If you are using NIO Connector you will want to supply these NIO
 Connector attributes


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



 If you are using SSL on NIO read SSL on NIO for that capability



 APR Native SSL would use these parameters






 Attribute
 Description

 SSLCACertificateFile

 See the mod_ssl documentation.


 SSLCACertificatePath

 See the mod_ssl documentation.


 SSLCARevocationFile

 See the mod_ssl documentation.


 SSLCARevocationPath

 See the mod_ssl documentation.


 SSLCertificateChainFile

 See the mod_ssl documentation.


 SSLCACertificateFile

 Name of the file that contains the concatenated certificates for the
 trusted certificate authorities. The format is PEM-encoded.


 SSLCACertificatePath

 Name of the directory that contains the certificates for the trusted
 certificate authorities. The format is PEM-encoded.


 SSLCARevocationFile

 Name of the file that contains the concatenated certificate revocation
 lists for the certificate authorities. The format is PEM-encoded.


 SSLCARevocationPath

 Name of the directory that contains the certificate revocation lists for
 the certificate authorities. The format is PEM-encoded.


 SSLCertificateChainFile

 Name of the file that contains concatenated certifcates for the
 certificate authorities which form the certifcate chain for the server
 certificate. The format is PEM-encoded.


 SSLCertificateFile

 Name of the file that contains the server certificate. The format is
 PEM-encoded.


 SSLCertificateKeyFile

 Name of the file that contains the server private key. The format is
 PEM-encoded. The default value is the value of SSLCertificateFile and in
 this case both certificate and private key have to be in this file (NOT
 RECOMMENDED).


 SSLCipherSuite

 Ciphers which may be used for communicating with clients. The default is
 ALL, with other acceptable values being a list of ciphers, with : used
 as the delimiter (see OpenSSL documentation for the list of ciphers
 supported).


 SSLDisableCompression

 Disables compression if set to true and OpenSSL supports disabling
 compression. Default is false which inherits the default compression
 setting in OpenSSL.


 SSLHonorCipherOrder

 Set to true to enforce the server's cipher order (from the SSLCipherSuite
 setting) instead of allowing the client to choose the cipher (which is the
 default).


 SSLPassword

 Pass phrase for the encrypted private key. If SSLPassword is not
 provided, the callback function should prompt for the pass phrase.


 SSLProtocol

 Protocol which may be used for communicating with clients. The default
 value is all, which is equivalent to SSLv3+TLSv1 with other acceptable
 values being SSLv2, SSLv3, TLSv1 and any combination of the three protocols
 concatenated with a plus sign. Note that the protocol SSLv2 is inherently
 unsafe.


 SSLVerifyClient

 Ask client for certificate. The default is none, meaning the client will
 not have the opportunity to submit a certificate. Other acceptable values
 include optional, require and optionalNoCA.


 SSLVerifyDepth

 Maximum verification depth for client certificates. The default is 10.



 Tweak these Connector timeout parameters to acomodate your requirement

 asyncTimeout

 connectionTimeout

 connectionUploadTimeout

 disableUploadTimeout

 executorTerminationTimeoutMillis

 keepAliveTimeout

 socket.soTimeout

 socket.unlockTimeout

 selectorTimeout
 sessionTimeout


 (yes..Mr Schultz is correct on the last statement)
 Martin-





  Date: Wed, 5 Mar 2014 15:12:02 +0200
  Subject: Re: java: src/network.c:441:
 Java_org_apache_tomcat_jni_Socket_send: Assertion failed
  From: dmitry.batiyevs...@ardas.dp.ua
  To: users@tomcat.apache.org
 
  Atmosphere upgrade didn't help
 
  Regards,
 
  Dmitry Batiyevskiy
 
  Ardas Group Inc.
 
  www.ardas.dp.ua
 
 
  2014-03-05 9:39 GMT+02:00 Dmitry Batiyevskiy 
 dmitry.batiyevs...@ardas.dp.ua
  :
 
   We are ok with tomcat 7.0.42 and old tcnative now, and may be next
   tcnative update will work appropriately
   We will try updating atmosphere before trying NIO anyway
  
   Regards,
  
   Dmitry Batiyevskiy
  
   Ardas Group Inc.
  
   www.ardas.dp.ua
  
  
   2014-03-04 23:18 GMT+02:00 Christopher Schultz 
   ch...@christopherschultz.net:
  
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA256
  
   Dmitry,
  
   On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote:
Howard, My connector config is the following (i've already posted
that):
   
Connector port=8443 maxHttpHeaderSize=8192 maxThreads=15000
enableLookups=false disableUploadTimeout=true acceptCount=100
scheme=https secure=true SSLEnabled=true compression=off
SSLCertificateFile=/opt/tomcat/mycompany.com.crt
SSLCertificateKeyFile=/opt/tomcat/mycompany.com.key /
   
Also -Dhttps.protocols=TLSv1 option

Re: Stream closed- IOException exception

2014-03-05 Thread Prashant Kadam

On Wed, Mar 5, 2014 at 7:11 PM, Prashant Kadam prashantkada...@gmail.comwrote:




 On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Prashant,

 On 3/3/14, 6:04 AM, Prashant Kadam wrote:
  please help ... I have removed whitespaces by adding jsp-config
  jsp-property-group url-pattern*.jsp/url-pattern
  trim-directive-whitespacestrue/trim-directive-whitespaces
  /jsp-property-group /jsp-config but still i am facing same
  error.

 This may or may not do anything.

  I tried to increase the buffer size also as, %@ page
  buffer=800kb autoFlush=false % but still same error

 Hm. With a huge buffer, the only reason the response would have been
 committed is if a flush() was being called somewhere. You said you
 gutted the struts actions, but it's possible that somewhere, Struts is
 internally flushing the buffer. (That would surprise me, honestly).
 Are you sure there are no errors occurring anywhere? Often, an error
 will cause the response to be committed.

 BTW you probably never want to use autoFlush=false unless you are
 watching the buffer very carefully. For debugging, it's fine, but you
 certainly don't want to do that on a regular basis.

  stuck on this issue for more than 2 weeks now and need to close it
  ASAP please help.

 Remember that this is a community made up of volunteers. This problem
 / ticket is *yours* and not ours to be solved ASAP. Everybody's issues
 need to be solved ASAP, of course. If you want something done ASAP and
 you can't do it yourself, then you'll have to pay someone else to do it.

  Any help/ pointer would be highly appreciated.
 
  one more things, we are using struts version 1 and tiles 2.2. as
  struts1 doesn't work with tiles2, we have used
  struts-tiles2-1.4.0-SNAPSHOT.jar, can this create any problem, but
  this combination work with tomcat version below 7.0.37 and giving
  issues from version 7.0.39.
 
  Can anybody please tell me what are the changes in between these
  two versions which can produce this errror ??

 You could take a look at the Changelog for version 7.0.39 (or .38) to
 see if anything looks probable. I recommend using a debugger as
 Konstantin suggests and trap the condition. You'll be able to unwind
 the stack to see what code is causing the response to be committed.



 hi Thanks for your reply.
 I started debugging the code and found some pointers but not able to fully
 identify the root cause.
 What I found is,

 In TilesRequestProcessor class

protected void doForward(
 String uri,
 HttpServletRequest request,
 HttpServletResponse response)
 throws IOException, ServletException {

 if (response.isCommitted()) {
 this.doInclude(uri, request, response);

 } else {
 super.doForward(uri, request, response);
 }
 }

 with version 7.0.39, somewhere
 org.apache.jasper.runtime.ServletResponseWrapperInclude.*isCommited* is
 setting to false, causing forward but response is already commited and
 throws IO Exception.
 with version 7.0.37, particularly for this request this flag sets to true
 and it works.

 any pointers on this ? how can I find from where this is setting to false ?



I found the class  *org.apache.coyote.Response* ... where this flag is
being set,
public void setCommitted(boolean v) {
this.commited = v;
}

its default value is false and in my case it does not come here when I
debug, so remains false. But when I use 7.0.37, this method gets called and
it sets this flag to true.

Is there any changes in tomcat which can cause this behavior ?

Thanks
Prashant Kadam


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

 iQIcBAEBCAAGBQJTFLrqAAoJEBzwKT+lPKRYYx0P/jQ065OqO2xG+TiWv8Nkyht8
 HMewLURHezpCkWM3Q2tCrV4mgTXLgvs1eOMBdi4LTjvzAdLjPNRBBQhR0bXjjIIS
 gAu92exfyuoBgN8mkgBTgZpmIFa/xPIbj+xDdImFHYcpHCrRw7ga4V9iyum27UQF
 JkXGz/qOegMattgF2k6Dgkz2UBN7QLwqnAqpaFo3m9XNqc6eQdTQWTzZ+MXX2tJ2
 dndK+Bu+sdlWDeCtnegGO8ieh5GH0SB67ygSnBC/FPQOTDKojTpG7XbvrKonviUH
 2u8S1gBuRClGGWXYv73LTCIYM5hpZA6S86nHD8UBciNTEx/rfLFtDGfpyb0lSVo8
 4/kt/XIuqzmnrFkV2+Do2/xmorAs3QADlkmaK1e0cT1yVCBGUwU1FfalELj6JICj
 Wc73VB2SPDgwnY8qS1haa8V+LHZq4KVj9M1ZVf1buA7sFQTHeMsezP7KMmySJ6GU
 Ht70ubSvCIiEiSKT/gBeRcaTr1G6tyD4mObrKoz87BDMJbfe5yfkhguDKa3xvZLa
 +4oVvROVYklE1ZVAvY4IUH+LHTpWIL9HJFtWxi2C+KE0ihs8wq+iA+KMdkwB4W7H
 9l231PiUE8ugya9K6qvDglPXhB5TvzIqpRoyb3lomESTwYuqDERYGRs3ouIVuJ3f
 vF1I9tIciTVKPwzRNESN
 =ukUm
 -END PGP SIGNATURE-

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




 --
 ~ Prashant Kadam




-- 
~ Prashant Kadam

Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

Chris,

On Tue, Mar 4, 2014 at 4:18 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 Dmitry,

 On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote:
  Howard, My connector config is the following (i've already posted
  that):
 
  Connector port=8443 maxHttpHeaderSize=8192 maxThreads=15000
  enableLookups=false disableUploadTimeout=true acceptCount=100
  scheme=https secure=true SSLEnabled=true compression=off
  SSLCertificateFile=/opt/tomcat/mycompany.com.crt
  SSLCertificateKeyFile=/opt/tomcat/mycompany.com.key /
 
  Also -Dhttps.protocols=TLSv1 option is passed to java machine
 
  The reason for me to use apr connector is https performance, isn't
  NIO much slower in that?

 I don't have any recent performance data, but using OpenSSL is
 apparently measurably faster than using JSSE.

 On the other hand, is the NIO connector does not crash, isn't that a
 point in its favor?


Can you please clarify your statements above? are you saying that OpenSSL
implies (or equals) NIO or APR?

I'm asking, because I only use NIO connector without SSL.

Re: Performance drop under load for Tomcat8/DBCP2 with respect to Tomcat 7/DBCP1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/5/14, 8:56 AM, Mark Thomas wrote:
 On 05/03/2014 13:38, Christopher Schultz wrote:
 My DataSource configuration:
 
 Resource name=jdbc/diagnosis description=JDBC connection
 to main CHADIS database auth=Container 
 type=javax.sql.DataSource maxActive=1 maxIdle=1 
 maxWait=1 url=[url] username=[user]
 password=[user] driverClassName=com.mysql.jdbc.Driver
 removeAbandoned=true removeAbandonedTimeout=30
 logAbandoned=true testOnBorrow=true validationQuery=/*
 ping */ SELECT 1 /
 
 Note that I have a single database connection in the pool.
 
 Not with DBCP 2 you don't. maxActive has been renamed to 
 maxTotal so you'll have the default (8 from memory)
 connections in the pool. This is likely to be a common problem.
 We probably need to add something to catch this, report a
 warning and set the correct attribute.
 
 Okay, I'll take a look at that. What I can observe practically
 is that only a single connection to my MySQL database has been
 made, whatever the reason. Perhaps that's part of the trouble.
 
 Hmm. I don't recall exactly when this was renamed in DBCP 2. It is 
 always possible the build you are using does what you think it
 does.

I checked the configuration reference for DBCP 2, and two important
configuration properties were renames: maxActive-maxTotal and
maxWait-maxWaitMillis. When a connection couldn't be obtained (for
whatever reason... possibly POOL-248), the checkout was waiting
forever instead of timing-out after 10 seconds.

I'm re-testing with the modified configuration, but still with a stock
8.0.3.

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

iQIcBAEBCAAGBQJTFzk3AAoJEBzwKT+lPKRYAs0P/0/nCg1LQnTnemwrDgExFkXW
HtONMDSyJE77UrIemf+apSBq0OU34Vym4tBJf8asx+kyRSZifVWQp01lzl9CPZm7
d5RIfbsvfCimafsKGipqAFskNeFNCXH6RNEMwcAR0gMBijIlQd0IArL9OOuSJVHA
OrYaq38Yi56Tq2ENcjDTn+fjyJ/IEcluNuoI2lBqgTM3UmRxF1ItjditTzTkC4NW
oc3BLguoyOokOymJ9AQn2PuP0EtrrwnWS69Q/HiKaNLmrawVGDqoA2QDjlZF3XkM
Q2hP4EJSoDPFxIrTF+JiEv6pPt2PbtlC+JrjT04tJdnApl29Q2zalHdnudOSO9M5
80ivyU7mEgW1gwR5m48FKGZGB8l5UkQu+RdvvhvTfipqmN5rdqP/NjSsRok13YiV
HqE3g/8bcAMejDAjl916xa68npRXQLHPmKJMMSoc6Ri731INKflsAukScc5EIMmi
BI/EiJXgyNUK2L5MaWGgjrHNyzIlo1v8WFZAoMw0u5BtnNeWRSs/TE43sYUuiosu
FC8mJzg6U0f1CdSCCuIvm7Z3BwK4x9VW8ox30DomPA3Fs+p8O3PwAhLfjGEnMfDN
YgBmgS1WcXEfCQZZ5+VLrW7IiVotUB+3rY+Fd6Alo/vweXf230jJWIMY+BMa86rD
kk30PQpoyViGIztqxyHZ
=SLmC
-END PGP SIGNATURE-

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

Re: Performance drop under load for Tomcat8/DBCP2 with respect to Tomcat 7/DBCP1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/5/14, 9:48 AM, Christopher Schultz wrote:
 Mark,
 
 On 3/5/14, 8:56 AM, Mark Thomas wrote:
 On 05/03/2014 13:38, Christopher Schultz wrote:
 My DataSource configuration:
 
 Resource name=jdbc/diagnosis description=JDBC
 connection to main CHADIS database auth=Container 
 type=javax.sql.DataSource maxActive=1 maxIdle=1 
 maxWait=1 url=[url] username=[user] 
 password=[user] driverClassName=com.mysql.jdbc.Driver 
 removeAbandoned=true removeAbandonedTimeout=30 
 logAbandoned=true testOnBorrow=true
 validationQuery=/* ping */ SELECT 1 /
 
 Note that I have a single database connection in the pool.
 
 Not with DBCP 2 you don't. maxActive has been renamed to 
 maxTotal so you'll have the default (8 from memory) 
 connections in the pool. This is likely to be a common
 problem. We probably need to add something to catch this,
 report a warning and set the correct attribute.
 
 Okay, I'll take a look at that. What I can observe practically 
 is that only a single connection to my MySQL database has been 
 made, whatever the reason. Perhaps that's part of the trouble.
 
 Hmm. I don't recall exactly when this was renamed in DBCP 2. It
 is always possible the build you are using does what you think
 it does.
 
 I checked the configuration reference for DBCP 2, and two
 important configuration properties were renames:
 maxActive-maxTotal and maxWait-maxWaitMillis. When a connection
 couldn't be obtained (for whatever reason... possibly POOL-248),
 the checkout was waiting forever instead of timing-out after 10
 seconds.
 
 I'm re-testing with the modified configuration, but still with a
 stock 8.0.3.

Oddly enough, things seem to work with only an updated configuration:
setting maxInitial and maxTotal instead of maxActive and maxWaitMillis
instead of maxWait (actually, I have both sets of configuration in
there, so I can start Tomcat 7 or Tomcat 8 with the same context.xml
file). It still takes 5 seconds to render the whole page, but that's
/my/ problem, now ;)

I'll see if I can tell what the difference is between the two
configurations using JMX. When using maxActive, I should have gotten
the default of 8 connections but instead I got a single connection
that got stuck somehow under some load (authentication and initial
page-load worked, so the connection /was/ available at some point).

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

iQIcBAEBCAAGBQJTFzxBAAoJEBzwKT+lPKRYnGYQALVDmUdeBGkZPTdv7c6pmbQG
t/aAK49JCjrOZ2CRgdwbNgBNByeTY6dpBVtp/S9S9yigYRkfGq0Dlkp0496rGtyz
1ihR0g3Af37DCaQiBKgJEYlhVJGvpNBTPTQYhX1U0kbv0e807nfYrqXmk0YguKeM
z2Ca6GxhlNy8uW/FWhXraSICCFV4crrMn9r01qPcOPjLhCRm0yqBLJzRHKY8XSEK
UsDBMp9J93gOAf5wh7mqFUEVbJ4RbPouP7UmgSqAiv1kUHoGpMCNBtu8P1CFjIQh
7vSCe89+UIkJPPi2QN4qZ9atF/LZYyEer9tAPF6SHpGk7C4UFEG16AdDtPBxuYDE
zw5HZqrl1y/Ugrr62+MOrIjYMzecCTgAAOPdzkqc+Dh+BGgZaHKPg/Bvz9Ch+Doo
tythI27HxFyMCAXSwm17BRtCHwbxVAzM6V3q5Ns4KMc+tNwwyxxTHhQdfCIpYnXQ
2A2iOMGy6WFxHy8FR1dljdVp2zxJN3W+xNGESw/1y0DmKkC1HI49i/o4aV+mXD1V
e7wI7jBJLKZ6X8J7AbWJp4NzEykHVqlWRdr07nPcWlQN5pd9sJSB6f15OtgDkw+o
iTRLZ642lMtyNWD8jhCDcnZNG+Q5G2h2eLmhbaFCgfnsOynNQpe2T47jZJYnrzcI
JPmg/zqYsxMBfI7kHnK5
=tWti
-END PGP SIGNATURE-

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

Re: Tomcat 7.0.52 NIO + Atmospere 1.0.18 damaged responses

On Wed, Mar 5, 2014 at 8:35 AM, Jan Dosoudil jan.dosou...@aura.cz wrote:

Hi,
we have application running on Tomcat 7.0.52 with Nio connector (a lot
older versions too), it uses MyFaces (2.1.12), RichFaces (4.3.5),
Atmosphere framework (1.0.18). Atmosphere framework is configured to use
long-polling with Tomcat Nio comet support.

I searched atmosphere google groups mail list, earlier, this morning, for

tomcat nio ssl

and found,

https://groups.google.com/forum/?fromgroups#!searchin/atmosphere-framework/tomcat$20nio$20ssl/atmosphere-framework/J685km4oOvM/2qZMzo4wyfAJ

that topic mentioned something similar to what you are stating here, and i
think they were using same/similar version of atmosphere (1.0.1x).

Sometimes simple request takes a long time to finish (correlates with
connectionTimeout set on Connector) and response is damaged. Here is
example of damaged response from server:

HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=C524EA667CA4087407A5DCDEA1712E53; Path=/app/;
HttpOnly
Location: http://192.168.1.156:8080/app/login
Content-Length: 0
Date: Tue, 28 Jan 2014 16:10:54 GMT

Response packet contains exactly this data, no more data (headers) before
0. Example contains redirect but problem appears in JSF pages too. 0 is
end of chunked encoded response.

Problem went away by switching atmosphere from long-polling to WebSockets

+1 and this was mentioned in that thread (URL above), too.

so I think there may be problem in Atmospere framework long polling and
Tomcat async support. I've found workaround using socket.bufferPool=0 but
i think it's not final solution.

I don't have simple testcase to easily reproduce this problem. I've tried
turning on Tomcat debug logs, debugging Tomcat and so on but without usable
results. My opinion is that atmosphere framework uses NioChannel which
doesn't own but I'm not able to confirm or reject it.

Can you suggest me how to debug this problem or give me some tip to find
final solution?

have you considered upgrading to latest atmosphere version, retesting your
app, and sending a mail to atmosphere list about these issues?

also, is it a requirement or preference to use long-polling instead of
websocket? usually, i think it is default or recommended to upgrade to
websocket, and fallback to long-polling. is long-polling to support target
multiple-servers/platforms and/or clients?

Thanks,
Jan Dosoudil

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

Re: Stream closed- IOException exception

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Prashant,

On 3/5/14, 9:14 AM, Prashant Kadam wrote:
 On Wed, Mar 5, 2014 at 7:11 PM, Prashant Kadam
 prashantkada...@gmail.comwrote:
 
 
 
 
 On Mon, Mar 3, 2014 at 10:55 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Prashant,
 
 On 3/3/14, 6:04 AM, Prashant Kadam wrote:
 please help ... I have removed whitespaces by adding
 jsp-config jsp-property-group
 url-pattern*.jsp/url-pattern 
 trim-directive-whitespacestrue/trim-directive-whitespaces

 
/jsp-property-group /jsp-config but still i am facing same
 error.
 
 This may or may not do anything.
 
 I tried to increase the buffer size also as, %@ page 
 buffer=800kb autoFlush=false % but still same
 error
 
 Hm. With a huge buffer, the only reason the response would have
 been committed is if a flush() was being called somewhere. You said
 you gutted the struts actions, but it's possible that somewhere,
 Struts is internally flushing the buffer. (That would surprise me,
 honestly). Are you sure there are no errors occurring anywhere?
 Often, an error will cause the response to be committed.
 
 BTW you probably never want to use autoFlush=false unless you
 are watching the buffer very carefully. For debugging, it's fine,
 but you certainly don't want to do that on a regular basis.
 
 stuck on this issue for more than 2 weeks now and need to
 close it ASAP please help.
 
 Remember that this is a community made up of volunteers. This
 problem / ticket is *yours* and not ours to be solved ASAP.
 Everybody's issues need to be solved ASAP, of course. If you want
 something done ASAP and you can't do it yourself, then you'll have
 to pay someone else to do it.
 
 Any help/ pointer would be highly appreciated.
 
 one more things, we are using struts version 1 and tiles
 2.2. as struts1 doesn't work with tiles2, we have used 
 struts-tiles2-1.4.0-SNAPSHOT.jar, can this create any
 problem, but this combination work with tomcat version
 below 7.0.37 and giving issues from version 7.0.39.
 
 Can anybody please tell me what are the changes in between
 these two versions which can produce this errror ??
 
 You could take a look at the Changelog for version 7.0.39 (or .38)
 to see if anything looks probable. I recommend using a debugger as 
 Konstantin suggests and trap the condition. You'll be able to
 unwind the stack to see what code is causing the response to be
 committed.
 
 
 
 hi Thanks for your reply. I started debugging the code and
 found some pointers but not able to fully identify the root
 cause. What I found is,
 
 In TilesRequestProcessor class
 
 protected void doForward( String uri, HttpServletRequest
 request, HttpServletResponse response) throws IOException,
 ServletException {
 
 if (response.isCommitted()) { this.doInclude(uri, request,
 response);
 
 } else { super.doForward(uri, request, response); } }
 
 with version 7.0.39, somewhere 
 org.apache.jasper.runtime.ServletResponseWrapperInclude.*isCommited*
 is setting to false, causing forward but response is already
 commited and throws IO Exception. with version 7.0.37,
 particularly for this request this flag sets to true and it
 works.
 
 any pointers on this ? how can I find from where this is
 setting to false ?
 
 
 
 I found the class  *org.apache.coyote.Response* ... where this
 flag is being set, public void setCommitted(boolean v) { 
 this.commited = v; }
 
 its default value is false and in my case it does not come here
 when I debug, so remains false. But when I use 7.0.37, this
 method gets called and it sets this flag to true.
 
 Is there any changes in tomcat which can cause this behavior ?

I'm not sure. What did the stack trace look like when
setCommitted(true) was called? That's more important than knowing
/that/ it was called...

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

iQIcBAEBCAAGBQJTF0ryAAoJEBzwKT+lPKRY3UMQAMsYCwZmfwTNxD0nq6mshdIw
96btHgXF5ddUFGR3BnWHZNTPs3z3L9KVcnp7wEb9NQk3hlwUVIt4DXd0CFfSe3IJ
8CTh+Lrp3zlXpbUziDeouKI5SdBvPQin901siU9jt8xMQn9uvK9WoPb6b3+n6vD4
y1ROT0yjb+4ClOb0F0anGWsg34SdFqoojX2GOOxxnQ0jXnf9ek09HxcNmXxMg0cr
sYa6E0ORI6Xw9OikxW3gCjfIQuJ530Mn20mz0efJ37eRvmNsEjAHEbZjv+oeYj9O
d6j02hwybfPqIMIru2OLFNTSpOvRht0C3lF1mWNqGhI6sdeQCkMA/nAduz7R4E0H
ESPvm5i4ICl7MLQbyQWos8oxU7lyf7Mqs5f/u3hUGgT24ndt7dHbPOErWGeEh0fi
z9fTm9+GtmgsB0Ka3gOzBa3tbb/zW+0rGxG9MCVYe/ffNX5XvyMETP1y/Zf5di2l
hhAGa5t5vgAQzg+jpgt4EuYvk6mP+no31aUCgxzNLW+PmjMxB5nRtOqAWuxlZzx5
c0OWeefLG4oYlQqAWRBzt+B8/rPZ1Ozfkwo19VNRinKjCCf9gN+MO/M6GIJ79vhe
hSmxihGAsaGBgX4zFyhDJpFF27LzjQ+MQXfA4xvOaFIkMYuJbzavX/N4u+hVtllL
Gq5bmSbroAuBqTP/ORxe
=RyM3
-END PGP SIGNATURE-

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

Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howard,

On 3/5/14, 9:45 AM, Howard W. Smith, Jr. wrote:
 Chris,
 
 On Tue, Mar 4, 2014 at 4:18 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Dmitry,
 
 On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote:
 Howard, My connector config is the following (i've already
 posted that):
 
 Connector port=8443 maxHttpHeaderSize=8192
 maxThreads=15000 enableLookups=false
 disableUploadTimeout=true acceptCount=100 scheme=https
 secure=true SSLEnabled=true compression=off 
 SSLCertificateFile=/opt/tomcat/mycompany.com.crt 
 SSLCertificateKeyFile=/opt/tomcat/mycompany.com.key /
 
 Also -Dhttps.protocols=TLSv1 option is passed to java machine
 
 The reason for me to use apr connector is https performance,
 isn't NIO much slower in that?
 
 I don't have any recent performance data, but using OpenSSL is 
 apparently measurably faster than using JSSE.
 
 On the other hand, is the NIO connector does not crash, isn't
 that a point in its favor?
 
 
 Can you please clarify your statements above? are you saying that
 OpenSSL implies (or equals) NIO or APR?

APR implies OpenSSL, and I suppose vice-versa. APR is native code and
uses OpenSSL for its SSL engine. All of the pure-Java connectors (BIO,
NIO, and possible a soon-to-be-available NIO2 connector) all use JSSE
(Java Secure Sockets Extension) for SSL. For whatever reason, OpenSSL
is measurably faster than JSSE.

If you are fronting Tomcat with a web server which terminates SSL
itself, then I see no particular reason to use the connectors over the
NIO connectors.

(Note that you can still use APR for its entropy capabilities even if
not using it for SSL. You'll get session ids coming from OpenSSL's
random source instead of Java's. I'm not sure that matters too much.)

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

iQIcBAEBCAAGBQJTF0qNAAoJEBzwKT+lPKRYkIUQALqutaNWH1pLL1Gg89RgHyb+
01ORV9O6q2fwtsIgW5WPurZr6gJAcf8K2C1bAkE6WCudgLrHjaTwQtb5peWFqHr0
IiCLa2bVxkDXDPFy5ESViPTML6UPiOHBXa707ZAK3vzRB5jy6fHbqMVvPBRx4CzD
T0jKAqU9Odj38QBaUWvCi1BNgc0J5i4OyXBDNJmchyB0G6tN29vYo9zpaUnl972e
4qLzmWEGBzUnQ6y2zTga2fOZQJ4Lu5hQCLYmoCM84sU1Xl9BjHJ1Tn1mWm7jEm7V
zMlIgFlJ/y65AUCqSRerMO5V5y4N+44CeQ2WV5v3hes4htAqRV7BFOgCfQW8e6Ng
oqn4KLQU81rCOsN61tQIv1j17wkP6vux9WbaDScr+UVfjFZgdygaZvOLkmDs/bXG
+b3DNsGVswOU4it2Y/cp6NAzwWDQfdfQUYDn9U/XOi9MnYSXNf+2dorTqnUhZ3Y7
mbxrCFpwKdbgXTkvs1UPwOZVhJ8dBuno/HofKuqbd+s9SkF/eXZNdyWolRUQ8sdK
KFWgByHW+18IM1RiBieu9/iGA1U4nUz0HvLo0UxXpN1GAXO/67/Hv2h/LiqB/tQh
yVFbvEZV5bR64D9FoPFReGQG4as2NBfIrbFz4XhqHwps5DDYm7WsS4hK87PE7fNC
qeyeWruqGubsZfwDrfft
=ihsJ
-END PGP SIGNATURE-

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

Re: Configuring mod_jk with multiple Apache HTTPD Virtual Hosts

2014-03-05 Thread Rainer Jung

On 04.03.2014 23:09, Doug Strick wrote:
 The F5 issues were just due to poor environment configuration.  Each F5 VIP
 was sending traffic to the same pool and that pool was only configured for
 1 member.  That 1 member IP/port was used by several apache virtual hosts.
  So basically I never knew which virtual host was getting the request which
 meant some requests were going to listeners not running mod_jk.  Always fun
 joining a new company and having to piece together what someone else has
 done.
 
 Please remember that over 90% of these configs were created by the Adobe CF
 webserver config utility so I question some of it as well.  Here is what's
 being used in the uriworkermap.properties:
 
 /cfformgateway/* = cfusion
 /CFFormGateway/* = cfusion
 /flex2gateway/* = cfusion
 /flex2gateway = cfusion
 /cffileservlet/* = cfusion
 /CFFileServlet/* = cfusion
 /cfform-internal/* = cfusion
 /flashservices/gateway/* = cfusion
 /flex-internal/* = cfusion
 /rest/* = cfusion
 /*.cfml/* = cfusion
 /*.mxml = cfusion
 /*.as = cfusion
 /*.cfm = cfusion
 /*.cfm/* = cfusion
 /*.swc = cfusion
 /*.cfml = cfusion
 /*.cfc = cfusion
 /*.cfc/* = cfusion
 /*.cfr = cfusion
 /*.cfswf = cfusion
 /*.sws = cfusion
 /*.jsp = cfusion
 /*.hbmxml = cfusion
 
 
 This is what I'm seeing in the mod_jk log.  I've cut out a few sections of
 the Attempting to map context URI so there's less clutter.
 
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1131): Attempting to map URI
 '/' from 24 maps
 
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 jk_translate::mod_jk.c (3723): no match for / found
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1131): Attempting to map URI
 '/' from 24 maps
 
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 jk_map_to_storage::mod_jk.c (3798): no match for / found
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 map_uri_to_worker_ext::jk_uri_worker_map.c (1131): Attempting to map URI
 '/index.cfm' from 24 maps
 [
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 find_match::jk_uri_worker_map.c (958): Found a wildchar match
 '/*.cfm=cfusion'
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 jk_handler::mod_jk.c (2621): Into handler jakarta-servlet worker=cfusion
 r-proxyreq=0
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 wc_get_worker_for_name::jk_worker.c (115): found a worker cfusion
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 wc_get_name_for_type::jk_worker.c (292): Found worker type 'ajp13'
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 init_ws_service::mod_jk.c (1097): Service protocol=HTTP/0.9 method=GET
 ssl=false host=(null) addr=192.168.253.3 name=app1.dev5.abc.com port=80
 auth=(null) user=(null) laddr=192.168.253.61 raddr=192.168.253.3 uri=/
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_get_endpoint::jk_ajp_common.c (3161): acquired connection pool slot=0
 after 0 retries
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_marshal_into_msgb::jk_ajp_common.c (626): ajp marshaling done
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_service::jk_ajp_common.c (2450): processing cfusion with 2 retries
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): sending to ajp13
 pos=4 len=185 max=8192
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 12 34 00
 B5 02 02 00 08 48 54 54 50 2F 30 2E 39  - .4..HTTP/0.9
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 001000 00 01
 2F 00 00 0D 31 39 32 2E 31 36 38 2E 32  - .../...192.168.2
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 002035 33 2E
 33 00 FF FF 00 22 63 6F 6D 6D 65 72 63  - 53.3app1
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 003065 2E 64
 65 76 35 2E 6C 69 66 65 74 65 63 68 6E  - dev5.abc
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 00406F 6C 6F
 67 69 65 73 2E 63 6F 6D 00 00 50 00 00  - .com..P..
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 005002 A0 09
 00 27 54 4C 54 53 49 44 3D 31 38 36 35  - 'TLTSID=1865
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 006037 36 41
 32 41 33 45 35 31 30 41 33 30 30 30 33  - 76A2A3E510A30003
 [Tue Mar 04 16:36:50 2014] [5763:140265396258560] [debug]
 ajp_connection_tcp_send_message::jk_ajp_common.c (1184): 007045 43 39
 33 42 35 31 31 39 39 42 43 00 A0 08 00  -

Problem with mod_proxyajp and Tomcat 7

2014-03-05 Thread Teresa Fasano


Hi,
I have a communication problem between Apache and Tomcat with mod_proxy_ajp.
The Apache version is 2.2.15.
The problem occurred only with Tomcat 7 ( the same problem occurred with 
various version 7.0.x ), while it works with Tomcat 6.

The configuration of mod_proxy_ajp is

ProxyPass / share ajp :/ / 127.0.0.1:8009 / share
ProxyPassReverse / share ajp :/ / 127.0.0.1:8009 / share

The error is 400:
 GET / share / HTTP/1.1  400

In tomcat logs there are no problems/error .
Recalling the application directly on the HTTP port of the tomcat ( 8080 
) everything works.

So it seems a problem with mod_proxy_ajp .
Increasing the level of the logs I see :
[ Wed March 05 15:07:19 2014 ] [ debug] mod_proxy_ajp.c (269) : proxy : 
APR_BUCKET_IS_EOS
[ Wed March 05 15:07:19 2014 ] [ debug] mod_proxy_ajp.c (274) : proxy : 
data to read (max 8186 at 4)
[ Wed March 05 15:07:19 2014 ] [ debug] mod_proxy_ajp.c (289) : proxy : 
got 0 bytes of data
[ Wed March 05 15:07:19 2014 ] [ debug] ajp_header.c (687) : 
ajp_read_header : 04 ajp_ilink_received
[ Wed March 05 15:07:19 2014 ] [ debug] ajp_header.c (697 ) : 
ajp_parse_type : got 04
[ Wed March 05 15:07:19 2014 ] [ debug] ajp_header.c (516) : 
ajp_unmarshal_response : status = 400


What is the matter?
Teresa

--
--
L'educazione è il pane dell'anima
--

Teresa Fasano

CINECA
System and Technologies Department
Middleware and Infrastructure Group
Via Magnanelli, 6/3
Casalecchio di Reno (Bologna) ITALY

web: http://www.cineca.it
e-mail:  t.fas...@cineca.it
phone:   +39 051 61 71 364


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

Re: [OT] secure reverse proxy to my tomcat server HELP NEEDED

2014-03-05 Thread Jeff Haferman

André Warnier wrote:

 Jeff Haferman wrote:
 Jeff Top-Posting is not Bad because you have to scroll to the bottom to see 
 what you're after Haferman wrote:
 
 [...]

 quote :

 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing in e-mail?

 Bottom-posting preserves the logical order of the replies and is consistent 
 with the 
 Western reading direction from top to bottom.

 unquote.

 My comment was not meant to start a flame war, just to remind you (and 
 gently, at that) of 
 what the usage rules of this list are.  Even if for your own personal 
 communications 
 elsewhere you prefer to use another style, when you are going somewhere in 
 order to get 
 free help in resolving a problem of yours, and you obtain such help freely 
 given, it would 
 seem just mere politeness to abide by the customs of the place, no ?

[snip]

...you will note that I subsequently *did* bottom-post. This is an endless 
debate that has been going on for a couple of 
decades. I will abide by the mailing list rules, that does not mean I have to 
agree with the rationale. End of story.


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

Re: Problem with mod_proxyajp and Tomcat 7

2014-03-05 Thread Jim Jagielski


On Mar 5, 2014, at 11:23 AM, Teresa Fasano t.fas...@cineca.it wrote:

 Hi,
 I have a communication problem between Apache and Tomcat with mod_proxy_ajp.
 The Apache version is 2.2.15.
 The problem occurred only with Tomcat 7 ( the same problem occurred with 
 various version 7.0.x ), while it works with Tomcat 6.
 The configuration of mod_proxy_ajp is
 
 ProxyPass / share ajp :/ / 127.0.0.1:8009 / share
 ProxyPassReverse / share ajp :/ / 127.0.0.1:8009 / share
 

Why the spaces?


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

Re: Problem with mod_proxyajp and Tomcat 7

2014-03-05 Thread Teresa Fasano


Il 05/03/2014 17:34, Jim Jagielski ha scritto:

On Mar 5, 2014, at 11:23 AM, Teresa Fasano t.fas...@cineca.it wrote:


Hi,
I have a communication problem between Apache and Tomcat with mod_proxy_ajp.
The Apache version is 2.2.15.
The problem occurred only with Tomcat 7 ( the same problem occurred with 
various version 7.0.x ), while it works with Tomcat 6.
The configuration of mod_proxy_ajp is

ProxyPass / share ajp :/ / 127.0.0.1:8009 / share
ProxyPassReverse / share ajp :/ / 127.0.0.1:8009 / share


Why the spaces?


I wrote bad.

The configuration is:
ProxyPass /share ajp://127.0.0.1:8009/share
ProxyPassReverse /share ajp://127.0.0.1:8009/share




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




--
--
L'educazione è il pane dell'anima
--

Teresa Fasano

CINECA
System and Technologies Department
Middleware and Infrastructure Group
Via Magnanelli, 6/3
Casalecchio di Reno (Bologna) ITALY

web: http://www.cineca.it
e-mail:  t.fas...@cineca.it
phone:   +39 051 61 71 364


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

Re: Problem with mod_proxyajp and Tomcat 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Teresa,

On 3/5/14, 11:38 AM, Teresa Fasano wrote:
 Il 05/03/2014 17:34, Jim Jagielski ha scritto:
 On Mar 5, 2014, at 11:23 AM, Teresa Fasano t.fas...@cineca.it
 wrote:
 
 Hi, I have a communication problem between Apache and Tomcat
 with mod_proxy_ajp. The Apache version is 2.2.15. The problem
 occurred only with Tomcat 7 ( the same problem occurred with
 various version 7.0.x ), while it works with Tomcat 6. The
 configuration of mod_proxy_ajp is
 
 ProxyPass / share ajp :/ / 127.0.0.1:8009 / share 
 ProxyPassReverse / share ajp :/ / 127.0.0.1:8009 / share
 
 Why the spaces?
 
 I wrote bad.
 
 The configuration is: ProxyPass /share ajp://127.0.0.1:8009/share 
 ProxyPassReverse /share ajp://127.0.0.1:8009/share

This kind of thing works without a problem for me. Can you give us
some more information? There must be more in the log file.

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

iQIcBAEBCAAGBQJTF1YAAAoJEBzwKT+lPKRYAoUP/j1PfZD2eFC9B7HodJ/i+pmT
vAp/GfZyKnLgVIjicHp3sEw9TrVMxCdkX2l9hO8zwHYGEzFnJykmyzFRtflMThGK
FF0njPqHWKXJCH9kAeKYEjXsJKdzXEJvUjStdoFOqcNCBK5kXIfWDiK1xahk8ZpK
U2dtQrGlOq8+DTB5hZZ9TWKKZtaXfvCiEP05J70A4cW2Psd5frvzqzBTutjFL35U
FWWFcre7+vaZdONQudogm54qcV9xQjdqCS3nYnZNV98hWVcQyMmHq7Vgt4IexAMp
jjr8bzshQvEVQ4zEb6MfkrQqneQE2zVXwzVubTz3Clcv1vSnoKjpVMHWoeq78fcC
G2/dEuK9wGENI4HFNLD/BFLEQkZCXaQxq843A7NvED3+CpWq+cl/UIe9jBh0zRP6
nKcQXU4MtlyQm4cPFjeLeEXt4NUbIzJ6/i5rdjZog9QJHNFJVcR6/Yy3opidY89N
hnpAMVdkHfSzGt0Z+TDQcbCblzJg7IJ3eh1TNPrhm9RnUcEaamD/eoo/CUSv4ONF
JUYfKLy11E3SBxTh2GdPT5/wuy77v5L3dpiud267//On8HXB7mb64P+dGECCrqyE
+jWV1fLexiMDundSE0IclMNe6Uygi0E78fzPgZspcm5H9ZBDAx5bMqmdnniMoJMs
fN0lDOLGauHqB/6myB93
=mAEG
-END PGP SIGNATURE-

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

Re: Problem with mod_proxyajp and Tomcat 7

2014-03-05 Thread Teresa Fasano


Il 05/03/2014 17:51, Christopher Schultz ha scritto:


This kind of thing works without a problem for me. Can you give us
some more information? There must be more in the log file.

- -chris


Hi Cris,
the complete log of Apache reports:
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(45): proxy: AJP: 
canonicalising URL //127.0.0.1:8009/share/
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(1506): [client 
130.186.19.127] proxy: ajp: found worker ajp://127.0.0.1:8009/share for 
ajp://127.0.0.1:8009/share/
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy.c(998): Running scheme ajp 
handler (attempt 0)
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_http.c(1952): proxy: HTTP: 
declining URL ajp://127.0.0.1:8009/share/
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(698): proxy: AJP: 
serving URL ajp://127.0.0.1:8009/share/
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2011): proxy: AJP: has 
acquired connection for (127.0.0.1)
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2067): proxy: connecting 
ajp://127.0.0.1:8009/share/ to 127.0.0.1:8009
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2193): proxy: connected 
/share/ to 127.0.0.1:8009
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2380): proxy: AJP: 
backend socket is disconnected.
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2444): proxy: AJP: fam 2 
socket created to connect to 127.0.0.1
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(224): Into 
ajp_marshal_into_msgb
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(450): 
ajp_marshal_into_msgb: Done
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(269): proxy: 
APR_BUCKET_IS_EOS
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(274): proxy: data to 
read (max 8186 at 4)
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(289): proxy: got 0 
bytes of data
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(687): ajp_read_header: 
ajp_ilink_received 04

[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(697): ajp_parse_type: got 04
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(516): 
ajp_unmarshal_response: status = 400
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(537): 
ajp_unmarshal_response: Number of headers is = 0
[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(687): ajp_read_header: 
ajp_ilink_received 05

[Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(697): ajp_parse_type: got 05
[Wed Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(605): proxy: got 
response from 127.0.0.1:8009 (127.0.0.1)
[Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2029): proxy: AJP: has 
released connection for (127.0.0.1)


The problem is with the communication with Tomcat 7. No problems with 
Tomcat 6 (the same configuration of mod_proxy_ajp).
Recalling the application directly on the HTTP port of the tomcat ( 8080 
) everything works (HTTP 200).


--
--
L'educazione è il pane dell'anima
--

Teresa Fasano

CINECA
System and Technologies Department
Middleware and Infrastructure Group
Via Magnanelli, 6/3
Casalecchio di Reno (Bologna) ITALY

web: http://www.cineca.it
e-mail:  t.fas...@cineca.it
phone:   +39 051 61 71 364


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

Re: Can I use jmx to see jdbc pool variables/properties in Tomcat 6?

2014-03-05 Thread Charles Richard

On Tue, Mar 4, 2014 at 8:57 PM, Neven Cvetkovic
neven.cvetko...@gmail.comwrote:

 On Tue, Mar 4, 2014 at 2:56 PM, Charles Richard 
 charle...@thelearningbar.com wrote:

  On Tue, Mar 4, 2014 at 3:17 PM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
Can we still use Hibernate in our Spring application if we
configure the Data Source through a context.xml?
  
   Yup. You just need to tell Hibernate that you already have a
   DataSource. I'm not exactly sure how to do that, but I'm confident it
   can be done. You posted only the DataSource configuration itself and
   it didn't have a name (other than the id). You'll need to figure out
   how to get Hibernate to use an existing (external) DataSource rather
   than configuring it yourself as you have done.
  
   I'm really not sure how that could be done either but hopefully the
  developers here could help me with this.
 
 

Hi Neven,


 Charles,

 As Chris pointed out - there are two ways you can get a datasource into
 your Spring application:

 1) Spring managed resource (datasource) - e.g. C3P0, Tomcat Pool
 Datasource, etc... this is the one you've been using. Connection pool is
 implemented and managed by the Spring container. That usually doesn't
 register itself with JMX MBeanServer.

 You define datasource in the Spring configuration, e.g.

 bean id=myDatasource ... 
  ...
 /bean


 2) Tomcat / container managed resource (datasource) - defined by the
 Resource in the Tomcat configuration.

 See more details on JNDI entries here
 https://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html

 You will notice there are two ways to configure your resource in Tomcat
 container:

 (a) a global resource, so every deployed application will have access to
 the same entry, as defined in TOMCAT_DIR/conf/server.xml
 (b) per application resource, as defined in
 YOURAPP.war/META-INF/context.xml  (as Chris suggested).

 I'm trying to get option (b) to work and I'm getting this error:

Cannot create JDBC driver of class '' for connect URL 'null'
java.lang.NullPointerException

It also seems like Tomcat is not picking up my context.xml. Any suggestions?

My context.xml in /ourpath/META-INF:

 ?xml version=1.0 encoding=UTF-8?
Context antiJARLocking=true path=
  Resource name=jdbc/ourtest auth=Container
type=javax.sql.DataSource initialSize=0  maxActive=100 maxIdle=20
maxWait=1 mindIdle=0 name=xxx password=
removeAbandoned=true removeAbandonedTimeout=1800
url=jdbc:mysql://xxx.xxx.xxx.xxx/jdbc_testing /
/Context

My hibernate-context.xml:

?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jee=http://www.springframework.org/schema/jee;
xsi:schemaLocation=http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://www.springframework.org/schema/jee
   http://www.springframework.org/schema/jee/spring-jee-2.0.xsd;

jee:jndi-lookup id=dataSource jndi-name=java:comp/env/jdbc/ourtest /

Relevant section in web.xml:

  resource-ref
descriptionTLB Datasource/description
res-ref-namejdbc/ourtest/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
  /resource-ref

There are pros and cons for both approaches.

 Once you register your resource with JNDI, you can reference that
 datasource in your spring configuration with:

 jee:jndi-lookup id=dataSource jndi-name=jdbc/MyDataSource/

 (works in newer Spring 3.x, and possibly 2.x)

 You can see more details here:

 http://docs.spring.io/spring/docs/3.0.x/reference/xsd-config.html#xsd-config-body-schemas-jee

 http://docs.spring.io/spring/docs/2.5.6/reference/xsd-config.html#xsd-config-body-schemas-jee

 Hopefully, that answers your question.

 Cheers!
 Neven


Thanks,
Charles

Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

On Mar 5, 2014 11:09 AM, Christopher Schultz ch...@christopherschultz.net
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Howard,

 On 3/5/14, 9:45 AM, Howard W. Smith, Jr. wrote:
  Chris,
 
  On Tue, Mar 4, 2014 at 4:18 PM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  Dmitry,
 
  On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote:
  Howard, My connector config is the following (i've already
  posted that):
 
  Connector port=8443 maxHttpHeaderSize=8192
  maxThreads=15000 enableLookups=false
  disableUploadTimeout=true acceptCount=100 scheme=https
  secure=true SSLEnabled=true compression=off
  SSLCertificateFile=/opt/tomcat/mycompany.com.crt
  SSLCertificateKeyFile=/opt/tomcat/mycompany.com.key /
 
  Also -Dhttps.protocols=TLSv1 option is passed to java machine
 
  The reason for me to use apr connector is https performance,
  isn't NIO much slower in that?
 
  I don't have any recent performance data, but using OpenSSL is
  apparently measurably faster than using JSSE.
 
  On the other hand, is the NIO connector does not crash, isn't
  that a point in its favor?
 
 
  Can you please clarify your statements above? are you saying that
  OpenSSL implies (or equals) NIO or APR?

 APR implies OpenSSL, and I suppose vice-versa. APR is native code and
 uses OpenSSL for its SSL engine. All of the pure-Java connectors (BIO,
 NIO, and possible a soon-to-be-available NIO2 connector) all use JSSE
 (Java Secure Sockets Extension) for SSL. For whatever reason, OpenSSL
 is measurably faster than JSSE.

 If you are fronting Tomcat with a web server which terminates SSL
 itself, then I see no particular reason to use the connectors over the
 NIO connectors.

 (Note that you can still use APR for its entropy capabilities even if
 not using it for SSL. You'll get session ids coming from OpenSSL's
 random source instead of Java's. I'm not sure that matters too much.)

 - -chris

Understood. Thanks Chris!

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

 iQIcBAEBCAAGBQJTF0qNAAoJEBzwKT+lPKRYkIUQALqutaNWH1pLL1Gg89RgHyb+
 01ORV9O6q2fwtsIgW5WPurZr6gJAcf8K2C1bAkE6WCudgLrHjaTwQtb5peWFqHr0
 IiCLa2bVxkDXDPFy5ESViPTML6UPiOHBXa707ZAK3vzRB5jy6fHbqMVvPBRx4CzD
 T0jKAqU9Odj38QBaUWvCi1BNgc0J5i4OyXBDNJmchyB0G6tN29vYo9zpaUnl972e
 4qLzmWEGBzUnQ6y2zTga2fOZQJ4Lu5hQCLYmoCM84sU1Xl9BjHJ1Tn1mWm7jEm7V
 zMlIgFlJ/y65AUCqSRerMO5V5y4N+44CeQ2WV5v3hes4htAqRV7BFOgCfQW8e6Ng
 oqn4KLQU81rCOsN61tQIv1j17wkP6vux9WbaDScr+UVfjFZgdygaZvOLkmDs/bXG
 +b3DNsGVswOU4it2Y/cp6NAzwWDQfdfQUYDn9U/XOi9MnYSXNf+2dorTqnUhZ3Y7
 mbxrCFpwKdbgXTkvs1UPwOZVhJ8dBuno/HofKuqbd+s9SkF/eXZNdyWolRUQ8sdK
 KFWgByHW+18IM1RiBieu9/iGA1U4nUz0HvLo0UxXpN1GAXO/67/Hv2h/LiqB/tQh
 yVFbvEZV5bR64D9FoPFReGQG4as2NBfIrbFz4XhqHwps5DDYm7WsS4hK87PE7fNC
 qeyeWruqGubsZfwDrfft
 =ihsJ
 -END PGP SIGNATURE-

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

Trouble shooting refused connections

2014-03-05 Thread Bruce Weertman

Hey All:

We have a load balancer talking with tomcat’s running on multiple backend 
tomcat servers. The
tomcats are running web service applications. In doing testing, and as reported 
by customers,
we occasionally see refused connections. Not real often, but enough to be a 
head ache. 
We’re not sure where the problem is coming from. Suspects include (1) firewall, 
(2) load balancer 
(3) tomcat and perhaps the (4) the web app.  The volume of traffic is so high, 
that it becomes
a needle in a hay stack issue.

We are using the BIO connector and everything is HTTP. Our typical hit rates 
are dozens per second.

In my experimentation with Tomcat, if it runs out of threads and the accept 
queue fills,
there is no indication in (for example) catalina.out.

(see acceptCount and maxConnections in 
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html)

In production  maxConnections is the default of 200, but when looking at the 
number of connections
being processed by tomcat it’s rarely more than a couple dozen per instance. 
There’s always 
the possibility that it occasionally spikes. 

Anyway, the question is:  Is there any good way to see if tomcat is going into 
a state where it’s not accepting connections?
How would would I see this? Is it possible to see this ? 

Thanks for any help!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Optimization on simple requests

2014-03-05 Thread John Smith

Chris,

Thanks! Very helpful advice.

Best,
John


On Tue, Mar 4, 2014 at 1:54 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 John,

 On 3/4/14, 1:17 PM, John Smith wrote:
  Tomcat 7.0.42 on RHEL6.
 
  Assume that Tomcat is serving only one jsp page. Say it just
  rewrites a parameter value from the querystring to the html within
  the jsp.
 
  Also assume that there are ~200,000 users attempting to access that
  page - say almost simultaneously.
 
  What are the most relevant optimizations I can make to a single
  instance of tomcat for this scenario?

 So you want the highest-performance solution to the above scenario?

 As for Tomcat configuration, I would use the NIO connector with a
 large number of max connections (you'll have to see what practical
 size to give it) and a large number of threads in your thread pool
 (i.e. executor).

 NIO gets you the benefit of not blocking waiting for a second (or
 third, etc.) keepalive request to arrive over a connection before that
 thread can be used to do some real work. If all connections are
 Connection:close then this is less of an issue.

 If you have a big, beefy CPU relative to your Internet connection's
 bandwidth, you should probably enable compression on the connector:
 that will help you push bytes back to the client faster. You'll have
 to test whether or not this actually helps you in your particular
 situation, because you are trading CPU time for I/O time.

 Define only one Host element in your server.xml, and name it
 whatever your public hostname is: there is a slight optimization in
 the mapper that works slightly faster if you have exactly one Host
 element, and if that name matches the Host header from the request.
 (There is an even faster case for where there are no elements in the
 host list, then the default is used, but I'm not sure how to get a
 zero-element host list and yet still have a default host).

 Don't add any Valves or Filters that you don't absolutely need.

 I would remove any intermediate proxies that don't absolutely need to
 be there (like Apache httpd, Microsoft IIS, nginx, etc.). Tomcat
 itself comes fairly well-configured for performance out of the box
 (except for the use of the BIO connector, which gets the job done and
 it very stable and reliable, but certainly does not win any speed
 contests).

 If you want to optimize the hell out of the experience, you'll want to
 dump JSP: there's a lot of setup that goes into creating the
 environment in which a JSP page runs, and you don't mention that you
 need any of it above.

 If you just need to write HEADER + some value from query string +
 FOOTER, then try to do that all in 3 I/O writes, like this would be in
 a servlet:

 static final String HEADER = htmlheadtitleMy Fast
 Page/title/headbodyh1My Fast Page/h1pYour parameter value
 is i;
 static final String FOOTER = /i/p/body/html;

 void doGet(request, response) {

   ServletOutputStream out = response.getOutputStream();
   out.print(HEADER);
   out.print(request.getParameter(key));
   out.print(FOOTER);
 }

 To save network bandwidth, remove any non-essential whitespace from
 your text as I have done above.

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

 iQIcBAEBCAAGBQJTFiFPAAoJEBzwKT+lPKRYR5wP/iiaEcMIFxKBE9Rr9EP6ZhA+
 +fxznQ1QED232LlhvAAcAiAjnOOv/dzLxmC62dai9EZoV0/24WcMpYaEjaRo2jZu
 jIyeGb4Dn4ommJj7aPG+yesPRRTBY6j23SIauWbnRNBCggn/YCpOnjERuUHPtjMO
 G4kDeZaHGGjfirwTuPYCKxiKlYow6C4H8HUzLH84BvuktPPCgO16qbtCSCI0st+b
 av4pza4lzKSO3YsjS3PBNa7eI9q7zvLYqTeB7TziyLq7Jf5OOWPL73qUVJUgb54A
 M6GzvsdIYWHCigGZff0iHT3oNbDEteSVK7TPLP8+XzI8x8F+xsn5G8yv5wXhStDH
 44g2E2hZLwLhaaSiJqtxKGb2kTwoJA+CX33MnbngOkMGUO7SmRMlkx77d08GiYoA
 uvOKep8zz7R4Is8EZu5sdzUQSxPx2Y59uzQNMiBeER47d+hfu4aOl241QUrN2osO
 NsddzzXB6i9auvdhDdGUkNwbT2Iy8NtMKPBUvM+LWz2GC+8+/WyVeRjhQ5N3BUwc
 5YHCKrHVEgZR/NO7j6HvsqXBdUnbt8JNFp0O6XtkCUtlilDabki50wIqVXn/jEmc
 rG9YJKYDFDQdxJSEnpeZEw5+iDmORkSyIOEMw5htqVCCgeBRp2jeATVWKpdcM76G
 EJD/P6bdni3Vj7kthhjs
 =ADJI
 -END PGP SIGNATURE-

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

Re: Trouble shooting refused connections

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bruce,

On 3/5/14, 1:11 PM, Bruce Weertman wrote:
 We have a load balancer talking with tomcat’s running on multiple 
 backend tomcat servers. The tomcats are running web service 
 applications. In doing testing, and as reported by customers, we 
 occasionally see refused connections. Not real often, but enough
 to be a head ache.
 
 We’re not sure where the problem is coming from. Suspects include
 (1) firewall, (2) load balancer (3) tomcat and perhaps the (4) the
 web app.  The volume of traffic is so high, that it becomes a
 needle in a hay stack issue.

Can you describe your setup in a bit more detail? What kind of lb? How
many of them? Any fronting web server(s)? How many? How many Tomcat
instances?

What is/are your Connector configuration(s)?

 We are using the BIO connector and everything is HTTP. Our typical 
 hit rates are dozens per second.

Tomcat can certainly handle that kind of thing. If you have long
wait-times for your webapp, you might not be able to keep up.

 In my experimentation with Tomcat, if it runs out of threads and
 the accept queue fills, there is no indication in (for example) 
 catalina.out. (see acceptCount and maxConnections in 
 http://tomcat.apache.org/tomcat-7.0-doc/config/http.html)

Tomcat usually complains if you run out of threads.

 In production maxConnections is the default of 200, but when
 looking at the number of connections being processed by tomcat it’s
 rarely more than a couple dozen per instance. There’s always the
 possibility that it occasionally spikes.

What is the resolution of the data you have? Are you sampling with
some regularity?

 Anyway, the question is:  Is there any good way to see if tomcat
 is going into a state where it’s not accepting connections? How
 would would I see this? Is it possible to see this ?

Sure: connect to a specific Tomcat. If you get a connection refused,
then you are in this state.

Your load balancer should have a setting where you can choose a
back-end server explicitly if you want to go through the lb, or you
can just contact one directly.

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

iQIcBAEBCAAGBQJTF27qAAoJEBzwKT+lPKRYaF8P/iANR7Xzvi/D9LA40TmS2XB2
GsvI2mchm580mQF0mhn2sgcpytCc2RPTRKeWw2RgSsZNoOMH8Bnrdq3HLAD0cKlF
qv398kDvRN08GLh4qZSsfVT/XOQHSfLOf84ptB1otGyn4IqDc3sWe0lmtOPoO8uJ
SQeZcn5qhhHcyF6Nn6sRs0vTngR6gSr4eGroGF9QSZIyXPyIo5FjF4tDNfUhl2wf
wAl8FRrHpNDaCgk49frV/Y6eIMETVUIr7JV+viqE1a497oE0Iok5n2b79EOAPGwU
eDJ+JiBchqe+Qwy4CMCJctEKMagHXSxslY6xO/B7L3hK1d0Zo11zcLMtXx7C6aaa
z7uRsge+xlASxHhifw2/LkQuKBEzLEtPhUMUn6uxiATew5B/DqTgREEGpf9laC2o
egKrVR2i46iD/71y3fMWL+xqbz2i/Y5zsnNBQiDdt/YepZ+/k88VbPihPs8EavqG
U8d5DnTtl0wQvvbdv7KORAIYLP545pHiDcUEXEqHjABECoPIDqDoDmVLuq3mhZxL
q6BsCrWkU591CWme411IS95iLHY3W1a/9+INVYPZUB/99Eej6ntlvalpxyckAaPZ
cAc+dnXD03YedfAczmU/5jDlZEJezAgbUdtNaECmXtahtDF61Ew5yTdfRXq/LqXY
JK7aCZaJnbhtQQGSuO8J
=ZEI9
-END PGP SIGNATURE-

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

Re: Can I use jmx to see jdbc pool variables/properties in Tomcat 6?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles,

On 3/5/14, 12:07 PM, Charles Richard wrote:
 On Tue, Mar 4, 2014 at 8:57 PM, Neven Cvetkovic 
 neven.cvetko...@gmail.comwrote:
 
 On Tue, Mar 4, 2014 at 2:56 PM, Charles Richard  
 charle...@thelearningbar.com wrote:
 
 On Tue, Mar 4, 2014 at 3:17 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 Can we still use Hibernate in our Spring application if we
 configure the Data Source through a context.xml?
 
 Yup. You just need to tell Hibernate that you already have a 
 DataSource. I'm not exactly sure how to do that, but I'm
 confident it can be done. You posted only the DataSource
 configuration itself and it didn't have a name (other than
 the id). You'll need to figure out how to get Hibernate to
 use an existing (external) DataSource rather than configuring
 it yourself as you have done.
 
 I'm really not sure how that could be done either but
 hopefully the
 developers here could help me with this.
 
 
 
 Hi Neven,
 
 
 Charles,
 
 As Chris pointed out - there are two ways you can get a
 datasource into your Spring application:
 
 1) Spring managed resource (datasource) - e.g. C3P0, Tomcat Pool 
 Datasource, etc... this is the one you've been using. Connection
 pool is implemented and managed by the Spring container. That
 usually doesn't register itself with JMX MBeanServer.
 
 You define datasource in the Spring configuration, e.g.
 
 bean id=myDatasource ...  ... /bean
 
 
 2) Tomcat / container managed resource (datasource) - defined by
 the Resource in the Tomcat configuration.
 
 See more details on JNDI entries here 
 https://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html


 
You will notice there are two ways to configure your resource in Tomcat
 container:
 
 (a) a global resource, so every deployed application will have
 access to the same entry, as defined in
 TOMCAT_DIR/conf/server.xml (b) per application resource, as
 defined in YOURAPP.war/META-INF/context.xml  (as Chris
 suggested).
 
 I'm trying to get option (b) to work and I'm getting this error:
 
 Cannot create JDBC driver of class '' for connect URL 'null' 
 java.lang.NullPointerException

Uh. I hate getting this error. I have honestly never figured out what
the root cause is... the only thing that seems to work is to throw out
the whole Resource configuration and start from scratch. I'm fairly
sure it's a typo somewhere. Let's take a look...

 It also seems like Tomcat is not picking up my context.xml. Any
 suggestions?
 
 My context.xml in /ourpath/META-INF:
 
 ?xml version=1.0 encoding=UTF-8? Context
 antiJARLocking=true path=

Remove the path attribute: it's not legal here. If you want your
webapp to be the root context, then you need to name it ROOT.war (or
ROOT directory) within your webapps/ directory. Note that case
matters, even on case-insensitive filesystems like fat, ntfs, and hfs.
Do you really need autiJarLocking?

 Resource name=jdbc/ourtest auth=Container 
 type=javax.sql.DataSource initialSize=0  maxActive=100
 maxIdle=20 maxWait=1 mindIdle=0 name=xxx
 password= removeAbandoned=true
 removeAbandonedTimeout=1800 
 url=jdbc:mysql://xxx.xxx.xxx.xxx/jdbc_testing / /Context

You will need a driverClassName in there. For MySQL, it should be
com.mysql.jdbc.Driver if you are using Connector/J (which, of course,
you are). Note that 1800 seconds is a long time.

You have also misspelled minIdle, though the default for minIdle is
already 0.

 My hibernate-context.xml:
 
 ?xml version=1.0 encoding=UTF-8? beans
 xmlns=http://www.springframework.org/schema/beans; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xmlns:jee=http://www.springframework.org/schema/jee; 
 xsi:schemaLocation=http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
 http://www.springframework.org/schema/jee 
 http://www.springframework.org/schema/jee/spring-jee-2.0.xsd; 
  jee:jndi-lookup id=dataSource
 jndi-name=java:comp/env/jdbc/ourtest /

This I can't help with.

 Relevant section in web.xml:
 
 resource-ref descriptionTLB Datasource/description 
 res-ref-namejdbc/ourtest/res-ref-name 
 res-typejavax.sql.DataSource/res-type 
 res-authContainer/res-auth /resource-ref

This looks fine to me. My experience is that this section in web.xml
is not strictly necessary.

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

iQIcBAEBCAAGBQJTF3FMAAoJEBzwKT+lPKRY09EQAKf9HWAIyQlEkQoK4GqpVr+w
n5BnPmGsAYXbtF4nRRomPruzx9uDo2RsOMwpooiS4/2AqzGinhFtnpXGQ/fXuQkX
WzCv7FDy//LLlpmd0LeNuWq8hYwtbmP9Cfy9nItT0sBoov3smYYgioIkZc7RQGpG
WrMC4gYo0csQ/ZfMjI+kpMX6fWntckQNWRqvvjOsTJe3lXAAjkZ7kUGzRar3ew32
boyDrNv/Drxh5L2BhLoIJoosnnVNcdptohiVwcMPAyhhIMu/EC2PiMVgk1ilwNmf
1HsjZqpdZaESVGJ9HJhCKVM6NVgfiCG/Mmpq0qyud3tfQCMTGHk6cQCLAk69ttb3
FSAcPQlYIf0/qTopxlTfp8rQ/yRkEBFJVIkPto+2pprxH5QNRu3TMKBsvWUS2Svn

Re: Problem with mod_proxyajp and Tomcat 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Theresa,

On 3/5/14, 12:05 PM, Teresa Fasano wrote:
 Il 05/03/2014 17:51, Christopher Schultz ha scritto:
 
 This kind of thing works without a problem for me. Can you give
 us some more information? There must be more in the log file.
 
 - -chris
 
 Hi Cris, the complete log of Apache reports: [Wed Mar 05 17:54:16
 2014] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL
 //127.0.0.1:8009/share/ [Wed Mar 05 17:54:16 2014] [debug]
 proxy_util.c(1506): [client 130.186.19.127] proxy: ajp: found
 worker ajp://127.0.0.1:8009/share for ajp://127.0.0.1:8009/share/ 
 [Wed Mar 05 17:54:16 2014] [debug] mod_proxy.c(998): Running scheme
 ajp handler (attempt 0) [Wed Mar 05 17:54:16 2014] [debug]
 mod_proxy_http.c(1952): proxy: HTTP: declining URL
 ajp://127.0.0.1:8009/share/ [Wed Mar 05 17:54:16 2014] [debug]
 mod_proxy_ajp.c(698): proxy: AJP: serving URL
 ajp://127.0.0.1:8009/share/ [Wed Mar 05 17:54:16 2014] [debug]
 proxy_util.c(2011): proxy: AJP: has acquired connection for
 (127.0.0.1) [Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2067):
 proxy: connecting ajp://127.0.0.1:8009/share/ to 127.0.0.1:8009 
 [Wed Mar 05 17:54:16 2014] [debug] proxy_util.c(2193): proxy:
 connected /share/ to 127.0.0.1:8009 [Wed Mar 05 17:54:16 2014]
 [debug] proxy_util.c(2380): proxy: AJP: backend socket is
 disconnected. [Wed Mar 05 17:54:16 2014] [debug]
 proxy_util.c(2444): proxy: AJP: fam 2 socket created to connect to
 127.0.0.1 [Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(224):
 Into ajp_marshal_into_msgb [Wed Mar 05 17:54:16 2014] [debug]
 ajp_header.c(450): ajp_marshal_into_msgb: Done [Wed Mar 05 17:54:16
 2014] [debug] mod_proxy_ajp.c(269): proxy: APR_BUCKET_IS_EOS [Wed
 Mar 05 17:54:16 2014] [debug] mod_proxy_ajp.c(274): proxy: data to 
 read (max 8186 at 4) [Wed Mar 05 17:54:16 2014] [debug]
 mod_proxy_ajp.c(289): proxy: got 0 bytes of data [Wed Mar 05
 17:54:16 2014] [debug] ajp_header.c(687): ajp_read_header: 
 ajp_ilink_received 04 [Wed Mar 05 17:54:16 2014] [debug]
 ajp_header.c(697): ajp_parse_type: got 04 [Wed Mar 05 17:54:16
 2014] [debug] ajp_header.c(516): ajp_unmarshal_response: status =
 400 [Wed Mar 05 17:54:16 2014] [debug] ajp_header.c(537): 
 ajp_unmarshal_response: Number of headers is = 0 [Wed Mar 05
 17:54:16 2014] [debug] ajp_header.c(687): ajp_read_header: 
 ajp_ilink_received 05 [Wed Mar 05 17:54:16 2014] [debug]
 ajp_header.c(697): ajp_parse_type: got 05 [Wed Mar 05 17:54:16
 2014] [debug] mod_proxy_ajp.c(605): proxy: got response from
 127.0.0.1:8009 (127.0.0.1) [Wed Mar 05 17:54:16 2014] [debug]
 proxy_util.c(2029): proxy: AJP: has released connection for
 (127.0.0.1)
 
 The problem is with the communication with Tomcat 7. No problems
 with Tomcat 6 (the same configuration of mod_proxy_ajp). Recalling
 the application directly on the HTTP port of the tomcat ( 8080 )
 everything works (HTTP 200).

Please post your connector configuration for Tomcat 7 (and Tomcat 6
for that matter). There is nothing else different?

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

iQIcBAEBCAAGBQJTF3G4AAoJEBzwKT+lPKRYa/0P/Anm/ad6VjMl5CP9J3d8bpSE
jantzvu2qD7LJVw+y6dsGQE+d2gf8mbSQzyz6gAzqd5jNsH7hURVfm/TlL3emLfk
XXVJ0SI1GpTv6QaZVySd833qXywD5N0GiJk7f0VW0XfH+VWz2WwYGmHoG0Z4GSp3
DzdxTFozjgcqkN/8yKpiMNig3aOoMA+Tux9BYhaSg/dhV9pmAvtOLL8aboJsC8Zs
wbLnVQSmDDFjjwjDZzaXztJgFVTkGzOEpRoXgq8x2Da+twrMYiQqg/C7VIF7Hz34
5SdphNhkMdZKERFTBfCvLGTnRjhRithfwtqbvTMJjE63WUu3lqi5e66RIgQ4q2ag
tMsdEteYlEu06k6vo7mmS+p8qxT6afLt/xOpA2m4+YfKAQ7D52gpsmSx+B3zY7D7
Whj5cNdF+cvxfmgBwIS5Phlv+vH+2aiBCcwW+nvOZHRMCu1TGyKr0f6qGfg5eRWF
nRxbzCyJkzupIaM/WIn2RCxIQmF5uqGq87NmMqZ8xf5EhzrrUhKEiShYxYb4qvIn
ngpSYAkh7kogwXFyyKRcKAuPg2DBoM27z+2M1Rd062Gcw6uNoD+S8TuQypHNx2Jo
/wUzCvKfhQYL/eI8Tjo6sqDwxBA7JhhNV+HV0gQj2/j+P4ZWzOjosYDNwPUaBC1A
EkYJIKUTYKydEM2vXc/K
=atDi
-END PGP SIGNATURE-

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

Re: Optimization on simple requests

On Tue, Mar 4, 2014 at 1:54 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 John,

 On 3/4/14, 1:17 PM, John Smith wrote:
  Tomcat 7.0.42 on RHEL6.
 
  Assume that Tomcat is serving only one jsp page. Say it just
  rewrites a parameter value from the querystring to the html within
  the jsp.
 
  Also assume that there are ~200,000 users attempting to access that
  page - say almost simultaneously.
 
  What are the most relevant optimizations I can make to a single
  instance of tomcat for this scenario?

 So you want the highest-performance solution to the above scenario?

 As for Tomcat configuration, I would use the NIO connector with a
 large number of max connections (you'll have to see what practical
 size to give it) and a large number of threads in your thread pool
 (i.e. executor).

 NIO gets you the benefit of not blocking waiting for a second (or
 third, etc.) keepalive request to arrive over a connection before that
 thread can be used to do some real work. If all connections are
 Connection:close then this is less of an issue.

 If you have a big, beefy CPU relative to your Internet connection's
 bandwidth, you should probably enable compression on the connector:
 that will help you push bytes back to the client faster. You'll have
 to test whether or not this actually helps you in your particular
 situation, because you are trading CPU time for I/O time.

 Define only one Host element in your server.xml, and name it
 whatever your public hostname is: there is a slight optimization in
 the mapper that works slightly faster if you have exactly one Host
 element, and if that name matches the Host header from the request.
 (There is an even faster case for where there are no elements in the
 host list, then the default is used, but I'm not sure how to get a
 zero-element host list and yet still have a default host).

 Don't add any Valves or Filters that you don't absolutely need.

 I would remove any intermediate proxies that don't absolutely need to
 be there (like Apache httpd, Microsoft IIS, nginx, etc.). Tomcat
 itself comes fairly well-configured for performance out of the box
 (except for the use of the BIO connector, which gets the job done and
 it very stable and reliable, but certainly does not win any speed
 contests).

 If you want to optimize the hell out of the experience, you'll want to
 dump JSP: there's a lot of setup that goes into creating the
 environment in which a JSP page runs, and you don't mention that you
 need any of it above.

 If you just need to write HEADER + some value from query string +
 FOOTER, then try to do that all in 3 I/O writes, like this would be in
 a servlet:

 static final String HEADER = htmlheadtitleMy Fast
 Page/title/headbodyh1My Fast Page/h1pYour parameter value
 is i;
 static final String FOOTER = /i/p/body/html;

 void doGet(request, response) {

   ServletOutputStream out = response.getOutputStream();
   out.print(HEADER);
   out.print(request.getParameter(key));
   out.print(FOOTER);
 }

 To save network bandwidth, remove any non-essential whitespace from
 your text as I have done above.


+1 Chris.

What about, also, a servlet/filter to set header for caching resources on
the client for some period of time (if/when applicable)? :)



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

 iQIcBAEBCAAGBQJTFiFPAAoJEBzwKT+lPKRYR5wP/iiaEcMIFxKBE9Rr9EP6ZhA+
 +fxznQ1QED232LlhvAAcAiAjnOOv/dzLxmC62dai9EZoV0/24WcMpYaEjaRo2jZu
 jIyeGb4Dn4ommJj7aPG+yesPRRTBY6j23SIauWbnRNBCggn/YCpOnjERuUHPtjMO
 G4kDeZaHGGjfirwTuPYCKxiKlYow6C4H8HUzLH84BvuktPPCgO16qbtCSCI0st+b
 av4pza4lzKSO3YsjS3PBNa7eI9q7zvLYqTeB7TziyLq7Jf5OOWPL73qUVJUgb54A
 M6GzvsdIYWHCigGZff0iHT3oNbDEteSVK7TPLP8+XzI8x8F+xsn5G8yv5wXhStDH
 44g2E2hZLwLhaaSiJqtxKGb2kTwoJA+CX33MnbngOkMGUO7SmRMlkx77d08GiYoA
 uvOKep8zz7R4Is8EZu5sdzUQSxPx2Y59uzQNMiBeER47d+hfu4aOl241QUrN2osO
 NsddzzXB6i9auvdhDdGUkNwbT2Iy8NtMKPBUvM+LWz2GC+8+/WyVeRjhQ5N3BUwc
 5YHCKrHVEgZR/NO7j6HvsqXBdUnbt8JNFp0O6XtkCUtlilDabki50wIqVXn/jEmc
 rG9YJKYDFDQdxJSEnpeZEw5+iDmORkSyIOEMw5htqVCCgeBRp2jeATVWKpdcM76G
 EJD/P6bdni3Vj7kthhjs
 =ADJI
 -END PGP SIGNATURE-

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

understanding jdbc pool

2014-03-05 Thread S Ahmed

Hi,

With jdbc pool, is each socket connection in the pool handled by a separate
thread?

Say you have 20 connections set to be open at minimum, does that mean there
will be 20 threads?  If not, then there is a degree of serialization then
right?

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet


The Java version wasn't it.  Recompiled and redeployed with 1.7.0_25
and it had no effect.

The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
JCP on the client side and clicked Restore Security Prompts in the JCP.

There was also a problem with JSESSIONID not being sent to the server
which was causing the applets call to the server to get a missing sesssion
exception.  I don't know how that changes when it's the exact same jar
file that worked before.  We put some code into the applet to force the
JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled.

Sigh.  We still haven't identified what caused this in the first place and
we're running out of ideas.

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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet

2014-03-05 Thread Konstantin Kolinko

2014-03-06 0:30 GMT+04:00 Bill Davidson bill...@gmail.com:
 The Java version wasn't it.  Recompiled and redeployed with 1.7.0_25
 and it had no effect.

 The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
 JCP on the client side and clicked Restore Security Prompts in the JCP.

 There was also a problem with JSESSIONID not being sent to the server
 which was causing the applets call to the server to get a missing sesssion
 exception.  I don't know how that changes when it's the exact same jar
 file that worked before.  We put some code into the applet to force the
 JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled.


Session cookie is HttpOnly in Tomcat 7.

If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration

 Sigh.  We still haven't identified what caused this in the first place and
 we're running out of ideas.


 -
 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

Problem with jmxproxy / Tomcat 8.0.3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

For some reason, I'm not able to access my Tomcat's JMX beans remotely
using jconsole, etc. and so I figured I'd try using the jmxproxy
servlet in the manager webapp. I've deployed the manager webapp in the
same way I've done in many other installations... I'm fairly sure I
haven't screwed it up.

I get an exception when calling an open-ended get (i.e. it should
dump the entire JMX tree):

$ curl -v --user jmxproxy:jmxproxy http://localhost/manager/jmxproxy?get

* Adding handle: conn: 0x7fd780804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fd780804000) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 80 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 80 (#0)
* Server auth using Basic with user 'jmxproxy'
 GET /manager/jmxproxy?get HTTP/1.1 Authorization: Basic
 am14cHJveHk6am14cHJveHk= User-Agent: curl/7.30.0 Host: localhost 
 Accept: */*
 
 HTTP/1.1 200 OK
 Date: Wed, 05 Mar 2014 20:57:59 GMT
 Cache-Control: private
 Expires: Wed, 31 Dec 1969 19:00:00 EST
 Content-Type: text/plain;charset=ISO-8859-1
 Content-Length: 3079

Error - javax.management.RuntimeOperationsException: Exception
occurred trying to invoke the getter on the MBean
javax.management.RuntimeOperationsException: Exception occurred trying
to invoke the getter on the MBean
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:629)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
org.apache.catalina.manager.JMXProxyServlet.getAttribute(JMXProxyServlet.java:128)
at
org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:107)
...
...
...
Caused by: java.lang.IllegalArgumentException: Attribute cannot be null
... 32 more
* Connection #0 to host localhost left intact
[end of output]

Any idea what this might be?

I removed my own web application and launched fresh with nothing but
the manager and it's still failing. Here is the entirety of my
catalina.out after a fresh launch:

Mar 05, 2014 4:15:48 PM 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: $CATALINA_HOME/apache-tomcat-8.0.3/lib
Mar 05, 2014 4:15:48 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [ajp-nio-8225]
Mar 05, 2014 4:15:48 PM org.apache.tomcat.util.net.NioSelectorPool
getSharedSelector
INFO: Using a shared selector for servlet write/read
Mar 05, 2014 4:15:48 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 532 ms
Mar 05, 2014 4:15:48 PM org.apache.catalina.core.StandardService
startInternal
INFO: Starting service Catalina
Mar 05, 2014 4:15:48 PM org.apache.catalina.core.StandardEngine
startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.0.3
Mar 05, 2014 4:15:48 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor
$CATALINA_HOME/conf/Catalina/localhost/manager-c.xml
Mar 05, 2014 4:15:48 PM
org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Context/Valve} Setting property
'resolveHosts' to 'false' did not find a matching property.
Mar 05, 2014 4:15:49 PM org.apache.jasper.servlet.TldScanner scanJars
INFO: At least one JAR was scanned for TLDs yet contained no TLDs.
Enable debug logging for this logger for a complete list of JARs that
were scanned but no TLDs were found in them. Skipping unneeded JARs
during scanning can improve startup time and JSP compilation time.
Mar 05, 2014 4:15:49 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-nio-8225]
Mar 05, 2014 4:15:49 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 648 ms

I'm going to continue to investigate, but I thought someone might have
noticed this before.

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

iQIcBAEBCAAGBQJTF5U2AAoJEBzwKT+lPKRYTFIP/RzBzWqddv94qKmqiv2E+hl9
XfQlmu/bYlzNWX2Do2x/fk0Jl2//Bid+jPMwWHJMWyEpaXFLQUaAd8v1IBHmZnbA
+OVZ7mtS4P2Ostoazj4GYGOlv1diJz49Qpm0p/e377/DpaTPY+Um3OafxE7iT7Yv
t/uyo+VhupfyXddsdDYvyCuwrGs6oq5XsXXwaJnLKNBnRSmSiAV3CNPz7stXRXD9
R/9amTdmqaOrnBUVxvA3I8YLitDO8lkqxELxMhgkot/K0lFOo+wVDShA0/jay0xD
hZaqvMSIIfkXKYE4teX8Zfk/zY/Xc6iC7DA4YWo250bpYxGrsIl+skOgfcMBcSkq
sC/o4ZaipzA4hXd0yTNRQsR/sITFU5oMzfJ9z1co2/gPnnvmFN6rM/HWBR8pJkF8
kAJ3haTS9l5Te1UfC53hntIeGQa2lNQFNJxBKOeukCBlEVkRdIAW7V4V7ytlg1oX
2oaJj851ljlpWdQMgze9GHtMjOt4RCerhRwRRzPHzUszYC85Wg5ms+H8DlUDAJIw
YtYe7zmSgCeCsWrGuIFbPxAfhuOa2ZISI2ReNt0MhHhpBwkdHotJROJIAD0/N1pB
ImFWmMsOG4pnv3Z6lYRmUxFD87m2LSy/QwslUltLgqQp9vCDwMzb6rUu+a7yYHyt
Xv9ahNRr4ydtlJdObYhp
=m2c1
-END PGP SIGNATURE-

Re: Problem with jmxproxy / Tomcat 8.0.3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 3/5/14, 4:20 PM, Christopher Schultz wrote:
 All,
 
 For some reason, I'm not able to access my Tomcat's JMX beans
 remotely using jconsole, etc. and so I figured I'd try using the
 jmxproxy servlet in the manager webapp. I've deployed the manager
 webapp in the same way I've done in many other installations... I'm
 fairly sure I haven't screwed it up.
 
 I get an exception when calling an open-ended get (i.e. it
 should dump the entire JMX tree):
 
 $ curl -v --user jmxproxy:jmxproxy
 http://localhost/manager/jmxproxy?get
 
 * Adding handle: conn: 0x7fd780804000 * Adding handle: send: 0 *
 Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * -
 Conn 0 (0x7fd780804000) send_pipe: 1, recv_pipe: 0 * About to
 connect() to localhost port 80 (#0) *   Trying ::1... * Connected
 to localhost (::1) port 80 (#0) * Server auth using Basic with user
 'jmxproxy'
 GET /manager/jmxproxy?get HTTP/1.1 Authorization: Basic 
 am14cHJveHk6am14cHJveHk= User-Agent: curl/7.30.0 Host: localhost
  Accept: */*
 
  HTTP/1.1 200 OK  Date: Wed, 05 Mar 2014 20:57:59 GMT 
 Cache-Control: private  Expires: Wed, 31 Dec 1969 19:00:00 EST 
 Content-Type: text/plain;charset=ISO-8859-1  Content-Length: 3079 
  Error - javax.management.RuntimeOperationsException: Exception 
 occurred trying to invoke the getter on the MBean 
 javax.management.RuntimeOperationsException: Exception occurred
 trying to invoke the getter on the MBean at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:629)

 
at
 com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)

 
at
 org.apache.catalina.manager.JMXProxyServlet.getAttribute(JMXProxyServlet.java:128)

 
at
 org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:107)

 
...
 ... ... Caused by: java.lang.IllegalArgumentException: Attribute
 cannot be null ... 32 more * Connection #0 to host localhost left
 intact [end of output]
 
 Any idea what this might be?
 
 I removed my own web application and launched fresh with nothing
 but the manager and it's still failing. Here is the entirety of my 
 catalina.out after a fresh launch:
 
 Mar 05, 2014 4:15:48 PM
 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:
 $CATALINA_HOME/apache-tomcat-8.0.3/lib Mar 05, 2014 4:15:48 PM
 org.apache.coyote.AbstractProtocol init INFO: Initializing
 ProtocolHandler [ajp-nio-8225] Mar 05, 2014 4:15:48 PM
 org.apache.tomcat.util.net.NioSelectorPool getSharedSelector INFO:
 Using a shared selector for servlet write/read Mar 05, 2014 4:15:48
 PM org.apache.catalina.startup.Catalina load INFO: Initialization
 processed in 532 ms Mar 05, 2014 4:15:48 PM
 org.apache.catalina.core.StandardService startInternal INFO:
 Starting service Catalina Mar 05, 2014 4:15:48 PM
 org.apache.catalina.core.StandardEngine startInternal INFO:
 Starting Servlet Engine: Apache Tomcat/8.0.3 Mar 05, 2014 4:15:48
 PM org.apache.catalina.startup.HostConfig deployDescriptor INFO:
 Deploying configuration descriptor 
 $CATALINA_HOME/conf/Catalina/localhost/manager-c.xml Mar 05, 2014
 4:15:48 PM org.apache.tomcat.util.digester.SetPropertiesRule begin 
 WARNING: [SetPropertiesRule]{Context/Valve} Setting property 
 'resolveHosts' to 'false' did not find a matching property. Mar 05,
 2014 4:15:49 PM org.apache.jasper.servlet.TldScanner scanJars INFO:
 At least one JAR was scanned for TLDs yet contained no TLDs. Enable
 debug logging for this logger for a complete list of JARs that were
 scanned but no TLDs were found in them. Skipping unneeded JARs 
 during scanning can improve startup time and JSP compilation time. 
 Mar 05, 2014 4:15:49 PM org.apache.coyote.AbstractProtocol start 
 INFO: Starting ProtocolHandler [ajp-nio-8225] Mar 05, 2014
 4:15:49 PM org.apache.catalina.startup.Catalina start INFO: Server
 startup in 648 ms
 
 I'm going to continue to investigate, but I thought someone might
 have noticed this before.

So, I'm stupid: the command to dump everything is ?qry, not get.
Getting an error like this is no fun, though. I think I'll fix that.

There is another - legit this time - error that I can see when I call
?qry:

Mar 05, 2014 4:39:39 PM org.apache.catalina.mbeans.MBeanDumper dumpBeans
SEVERE: Error getting attribute
Catalina:type=WebappClassLoader,host=localhost,context=/manager jarPath
javax.management.ReflectionException: Cannot find getter method getJarPath
at
org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:461)
at
org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:180)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)

Re: understanding jdbc pool

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ahmed,

On 3/5/14, 3:15 PM, S Ahmed wrote:
 With jdbc pool, is each socket connection in the pool handled by a
 separate thread?

Why would a JDBC connection need a thread?

 Say you have 20 connections set to be open at minimum, does that
 mean there will be 20 threads?

No.

 If not, then there is a degree of serialization then right?

Serialization of what?

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

iQIcBAEBCAAGBQJTF5ooAAoJEBzwKT+lPKRYsYMP/ixF132G84VhwCGrO980XZH3
tGs5kt4rihKCK43vKviyXrpTJIhBMuvJkdinhXFeZ5ZtRUv0AyudAPUT0o8QRXwA
rpGIR+BQPZivmB39h0Er+YwGL+uB06lspJKCFr8ARq4IwMLUQEaDdjxirh6lGOBB
1CIz6qvZoNop6ZGtYQdtGbVP5GmGpPEz609Q3q9KIZ7gIk98bKiLIN+RmzyfdaGk
0nA4qYETwQQnZ+ymZ4lDKC6G3D2Q8+x3eJWQRVd8fQdaspAnU/zkA7I3Eb8jnRoq
HU1VaUVtFeY8Z8hkHnVrwumXQtMUG7qArc6BZXKC99eOvl+0LQpxHeE/afza1SfT
zpxmRCL8YSNMTw+W0Tgmjn2JvoOak+rGSM8yW+/LRYNdgNPt/Y0md+Vt6lv/c8kC
Dyy3vyTnG0D73U5yZSuzyJX69h2Lj//bKcOkcWRdsIE8J1/borlyVJbgiSJjNdnk
MJdPf0VmAqUeOloYyrQLrmeuQXiCnaYPgizOyGLa9FxW5sHrXAwRB9wUkyCu62gV
A6hRNZUv9t09N55ZstPzp4JY7d2fFCj7w6PRFJktCqbHQZnw56WXAmjUwQo9R7xU
0fiHfR4YaoW3Yzvha/H46OJ2E1ExoKP5+2SopBqkKdXRBzfeQ3DLypZ/t+5sFXYp
kAbkUjx4j6GKXuvi8TQB
=TGE9
-END PGP SIGNATURE-

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

Re: Performance drop under load for Tomcat8/DBCP2 with respect to Tomcat 7/DBCP1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 3/5/14, 10:01 AM, Christopher Schultz wrote:
 Oddly enough, things seem to work with only an updated
 configuration: setting maxInitial and maxTotal instead of maxActive
 and maxWaitMillis instead of maxWait (actually, I have both sets of
 configuration in there, so I can start Tomcat 7 or Tomcat 8 with
 the same context.xml file). It still takes 5 seconds to render the
 whole page, but that's /my/ problem, now ;)

I spoke too soon: it's still locking-up intermittently with 8.0.3...
hard to reproduce at this point.

I'll try with trunk as well.

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

iQIcBAEBCAAGBQJTF5p5AAoJEBzwKT+lPKRYXtAQAIGKEHafS1UdWQ6oO++cqgqa
Fl2a8opuvOaFzy2t6tMDImQzZptFevlNHzf9YtUWngTAdKB4wQ0fbRgr1jNIiRNC
KjndgisEWywA6+iU//+CRav9sdrCbS5GXA0cI2a/cxckyaslTFYo37jD02CgrUFG
Rbcp1pERfufidHE6nKSwe6LlsbUC3baWuUXPQ+Rw8R0n4Xg+DDtIqKezAqGnB5kW
efPXeCDkEJzQKqK4Z7Tsv36BJUhQvyIZa5OrFITQdxEJHRJ+TI24y6LEs1DrVo2o
uAXMlKq8rDLxIbHV6kKDaMPu67+BNswdNBaKp17g3ha+t235l0LTAI55ODNx4wMw
GEyFHFtz0xtRNbAvcWbKX/anjKC1Gz2AGALVy5OsNho6ZQbBVSLPsaXNskEhhsSX
G47bcwms10YVbFBSMinh3QWqM9GhrxMlWt5mIcav74hf73R3J8PAH2ri2SDM69/M
rcpyGSPKgZ6JHYNiN5+LaiKHOE9+pl08unLIYvmMln3BF6sYSD+J4vqjoiYJHqiz
P0B5/hIIvQDRQPMX88eZ8Zt6Uur2F0eTPAPyx3CczE9JhZYVw9Yb87lcA0mJczxG
A9OpQQqs2gf+6Q1+AUJjTIReqsRIZbKvK+BPYOFIPTTbTo5qbCoGYbhCzjMkSuTv
bTTEIJ0shtxkULT9KnHv
=m6GW
-END PGP SIGNATURE-

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

RE: tomcat 6 refuses mod_jk connections after server runs for a couple of days

2014-03-05 Thread Isaac Gonzalez

-Original Message-
From: Daniel Mikusa [mailto:dmik...@gopivotal.com] 
Sent: Tuesday, March 04, 2014 12:42 PM
To: Tomcat Users List
Subject: Re: tomcat 6 refuses mod_jk connections after server runs for a couple 
of days

On Mar 4, 2014, at 1:55 PM, Isaac Gonzalez igonza...@autoreturn.com wrote:

 Dan,

 From: Daniel Mikusa [dmik...@gopivotal.com]
 Sent: Tuesday, March 04, 2014 6:20 AM
 To: Tomcat Users List
 Subject: Re: tomcat 6 refuses mod_jk connections after server runs for 
 a couple of days

 On Mar 4, 2014, at 6:32 AM, Rainer Jung rainer.j...@kippdata.de wrote:

 On 27.02.2014 23:06, Isaac Gonzalez wrote:
 Hi Christopher(and Konstantin), attached is a couple of thread dumps of 
 when we experienced the issue again today. I also noticed we get this 
 message right before the problem occurs:
 Feb 27, 2014 12:47:15 PM 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
 SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to 
 create new native thread) executing 
 org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, 
 terminating thread

 Is it a 32Bit system? You have 2GB of heap plus Perm plus native 
 memory needed by the process plus thread stacks. Not unlikely, that 
 you ran out of memory address space for a 32 bit process.

 The only fixes would then be:

 - switch to a 64 bit system

 - reduce heap if the app can work with less

 - improve performance or eliminate bottlenecks so that the app works 
 with less threads

 - limit you connector thread pool size. That will still mean that if 
 requests begin to queue because of performance problems, the web 
 server can't create additional connections, but you won't get in an 
 irregular situation as you experience now. In that case you would 
 need to configure a low idle timeout for the connections on the JK and TC 
 side.

 It may also be possible to lower the thread stack size with the -Xss option.

 Ok so we are 64 bit Linux with 1024k in the 64-bit VMwould lowering it to 
 64k be a bit too low? What sort of repercussions would we run into?
 Very helpful information by the way.

It depends on your apps, so you'll need to test and see.  If you go too low, 
you'll get StackOverflow exceptions.  If you see those, just gradually increase 
until they go away.

Dan

 -Isaac

 http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#threads_
 oom

 Might buy you some room for a few additional threads.

 Dan

 Regards,

 Rainer

 -
 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

Ok so the problem just happened again just now. Dan, Can you elaborate on how 
to configure limiting the connector thread pool size. I am also going to lower 
the thread stack size as you recommended. It seems like this problem creeps up 
when we have a hiccup in connectivity at our data center. Perhaps I also need 
to lower the idle timeout some more between tomcat and mod_jk. They are also 
between a firewall by the way, so I can configure a timeout between the two 
there as well. We aren't experiencing too many idle disconnects there.

-Isaac

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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet


On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.

If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration

I added this to some code that is executed by most requests that we use to
track operator activity:

Cookie[] cookies = request.getCookies();
if ( cookies != null ){
for ( Cookie cookie : cookies ){
operLog.append(\n).append(cookie.getName())
.append(=).append(cookie.getValue())
 .append(, 
secure=).append(cookie.getSecure())
   .append(, 
httpOnly=).append(cookie.isHttpOnly());
}
}
m_log.fatal(operLog.toString());

This is what that prints out in the log every time:

JSESSIONID=a big hex number, secure=false, httpOnly=false

So no, I don't think that's it.  We're set to send on any protocol.
Moreover, shouldn't the applet be sending httpOnly cookies even
if they are not visible to Javascript?

1. Why would it act differently with the load balancer than with a
direct connection?

2. Why would it have continued to fail over the load balancer after
we reverted to Tomcat 6?





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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet

2014-03-05 Thread Konstantin Kolinko

2014-03-06 2:11 GMT+04:00 Bill Davidson bill...@gmail.com:
 On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.

If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration

 I added this to some code that is executed by most requests that we use to
 track operator activity:

 Cookie[] cookies = request.getCookies();
 if ( cookies != null ){
 for ( Cookie cookie : cookies ){
 operLog.append(\n).append(cookie.getName())
 .append(=).append(cookie.getValue())
  .append(,
 secure=).append(cookie.getSecure())
.append(,
 httpOnly=).append(cookie.isHttpOnly());
 }
 }
 m_log.fatal(operLog.toString());

 This is what that prints out in the log every time:

 JSESSIONID=a big hex number, secure=false, httpOnly=false

 So no, I don't think that's it.  We're set to send on any protocol.
 Moreover, shouldn't the applet be sending httpOnly cookies even
 if they are not visible to Javascript?



The HttpOnly flag is used by cookies sent by server to the client.

There is no point checking it on request.getCookies(), as browsers do
not send it back  (neither do they send 'path', 'secure' etc.).

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

Re: Problem with jmxproxy / Tomcat 8.0.3

2014-03-05 Thread Konstantin Kolinko

2014-03-06 1:40 GMT+04:00 Christopher Schultz ch...@christopherschultz.net:

 On 3/5/14, 4:20 PM, Christopher Schultz wrote:
 All,

 For some reason, I'm not able to access my Tomcat's JMX beans
 remotely using jconsole, etc. and so I figured I'd try using the
 jmxproxy servlet in the manager webapp. I've deployed the manager
 webapp in the same way I've done in many other installations... I'm
 fairly sure I haven't screwed it up.

 I get an exception when calling an open-ended get (i.e. it
 should dump the entire JMX tree):

 $ curl -v --user jmxproxy:jmxproxy
 http://localhost/manager/jmxproxy?get


 There is another - legit this time - error that I can see when I call
 ?qry:

 Mar 05, 2014 4:39:39 PM org.apache.catalina.mbeans.MBeanDumper dumpBeans
 SEVERE: Error getting attribute
 Catalina:type=WebappClassLoader,host=localhost,context=/manager jarPath
 javax.management.ReflectionException: Cannot find getter method getJarPath


There was WebappClassLoader.getJarPath() method in Tomcat 7. It was
removed from TC8.


 at
 org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:461)
 at
 org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:180)
 at
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
 at
 com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)

 I'm not sure why this would be happening... could be mismatch with
 mbeans-descriptor? I'll investigate this one, too.

 - -chris

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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet


On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:

The HttpOnly flag is used by cookies sent by server to the client.

There is no point checking it on request.getCookies(), as browsers do
not send it back  (neither do they send 'path', 'secure' etc.).


Isn't that showing what the server is sending to the client?


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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet


On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:


The HttpOnly flag is used by cookies sent by server to the client.

There is no point checking it on request.getCookies(), as browsers do
not send it back  (neither do they send 'path', 'secure' etc.).



1. Isn't that what gets sent from the server to the client?

2. Why did it work when going direct without the load balancer?

3. Why did it sometimes work with IE even with the load balancer?

4. Why did it still fail when I reverted to Tomcat 6?

5. Why did it work before this release when we had TLS 1.1/1.2 enabled
in the client JCP?  Note that the load balancer is doing all of the SSL and
sending plain HTTP to httpd which is in turn talking AJP to Tomcat. While
our httpd does support HTTPS

6. New data point from last night: One of our support people uninstalled
Firefox and Chrome and the JRE from his Windows 8 laptop and then
reinstalled all of them.  All of them worked after that through the load
balancer on his laptop.  That was before the changes that we made to the
applet this morning for the cookie.



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

Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet