Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
NIO connector works without any issues, there is some problem in apr Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-03-05 16:13 GMT+02:00 Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua>: > Thanks > > Regards, > > Dmitry Batiyevskiy > > Ardas Group Inc. > > www.ardas.dp.ua > > > 2014-03-05 16:04 GMT+02:00 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 >>
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Mar 5, 2014 11:09 AM, "Christopher Schultz" 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): > >>> > >>> >>> 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 >
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): >>> >>> >> 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: 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): > > > > > 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: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Thanks Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-03-05 16:04 GMT+02:00 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 < >
RE: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
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 >: > > > 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): > >> > > >> > >> > enableLookups="false" disableUploadTimeout="true" acceptCount="100" > >&g
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
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 : > 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): >> > >> > > > 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? >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1 >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJTFkMeAAoJEBzwKT+lPKRYA+0P+wXFWLQnxRqzxwLtXMMK19jP >> FPsqAXQTLRvSM/FsaGONS3VuIeKciVsyPfEIE8V7GOihEyQfNGYQr4caY7oZD1W8 >> clJXWsc26Ez+eSYp8AHP0FORvu9hHXKWmf68ooBXwkC01v8iJD5XfpXZvev0VKWb >> HQQ/d/gP4f3wFSoQY2MYH+gsu6iayhueomHf/t2pckodztcVnmx61v3DjXjtgz3J >> HFsFay8tDTC5o/+OmU8PSzAZ2tRy8Ytd43dLNKq0YimR4Nb1LYE2MSjDoi49BvSX >> +Z9YYXIMWCPUST0GjrjhPGJ2/EKVt12zS8UJdfPvcSPyky/y2zJkwksJIB6gO8+2 >> Ps8IzGEXC0lM0yBaj2h4M28rVqA84k/oV0vBSbgvRnJYduFmM4qQzWEFStmMZxlN >> D0E5QVZyBM6ZQjXYN/PJU3u9l8RP8AJY5dwcOiCm3FBZcd0gmC0JbO8y4bXFB208 >> +zF63dGXqRVvLlSCmh9iqVqoqwgWGOJriKXZgqRmwtC1ovgkcfS16nxtGygh5mTG >> 4ark2XbFQUQeu5RhcrlYmb8yKRIVcbByrEAbh1vfvYfE+i01DO6StElmOnm3cJ9L >> K/ExFsOmpIyA4Z6A8Eyuq1t9TudZhhonT+6o7Or0Ve3PP8qh84HJuE7GFcT0gNAC >> z7iVVXDnPqrPjkYxEZe/ >> =tY82 >> -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
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 : > -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): > > > > > 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? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTFkMeAAoJEBzwKT+lPKRYA+0P+wXFWLQnxRqzxwLtXMMK19jP > FPsqAXQTLRvSM/FsaGONS3VuIeKciVsyPfEIE8V7GOihEyQfNGYQr4caY7oZD1W8 > clJXWsc26Ez+eSYp8AHP0FORvu9hHXKWmf68ooBXwkC01v8iJD5XfpXZvev0VKWb > HQQ/d/gP4f3wFSoQY2MYH+gsu6iayhueomHf/t2pckodztcVnmx61v3DjXjtgz3J > HFsFay8tDTC5o/+OmU8PSzAZ2tRy8Ytd43dLNKq0YimR4Nb1LYE2MSjDoi49BvSX > +Z9YYXIMWCPUST0GjrjhPGJ2/EKVt12zS8UJdfPvcSPyky/y2zJkwksJIB6gO8+2 > Ps8IzGEXC0lM0yBaj2h4M28rVqA84k/oV0vBSbgvRnJYduFmM4qQzWEFStmMZxlN > D0E5QVZyBM6ZQjXYN/PJU3u9l8RP8AJY5dwcOiCm3FBZcd0gmC0JbO8y4bXFB208 > +zF63dGXqRVvLlSCmh9iqVqoqwgWGOJriKXZgqRmwtC1ovgkcfS16nxtGygh5mTG > 4ark2XbFQUQeu5RhcrlYmb8yKRIVcbByrEAbh1vfvYfE+i01DO6StElmOnm3cJ9L > K/ExFsOmpIyA4Z6A8Eyuq1t9TudZhhonT+6o7Or0Ve3PP8qh84HJuE7GFcT0gNAC > z7iVVXDnPqrPjkYxEZe/ > =tY82 > -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 Dmitry, On 3/4/14, 2:48 AM, Dmitry Batiyevskiy wrote: > Howard, My connector config is the following (i've already posted > that): > > 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? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFkMeAAoJEBzwKT+lPKRYA+0P+wXFWLQnxRqzxwLtXMMK19jP FPsqAXQTLRvSM/FsaGONS3VuIeKciVsyPfEIE8V7GOihEyQfNGYQr4caY7oZD1W8 clJXWsc26Ez+eSYp8AHP0FORvu9hHXKWmf68ooBXwkC01v8iJD5XfpXZvev0VKWb HQQ/d/gP4f3wFSoQY2MYH+gsu6iayhueomHf/t2pckodztcVnmx61v3DjXjtgz3J HFsFay8tDTC5o/+OmU8PSzAZ2tRy8Ytd43dLNKq0YimR4Nb1LYE2MSjDoi49BvSX +Z9YYXIMWCPUST0GjrjhPGJ2/EKVt12zS8UJdfPvcSPyky/y2zJkwksJIB6gO8+2 Ps8IzGEXC0lM0yBaj2h4M28rVqA84k/oV0vBSbgvRnJYduFmM4qQzWEFStmMZxlN D0E5QVZyBM6ZQjXYN/PJU3u9l8RP8AJY5dwcOiCm3FBZcd0gmC0JbO8y4bXFB208 +zF63dGXqRVvLlSCmh9iqVqoqwgWGOJriKXZgqRmwtC1ovgkcfS16nxtGygh5mTG 4ark2XbFQUQeu5RhcrlYmb8yKRIVcbByrEAbh1vfvYfE+i01DO6StElmOnm3cJ9L K/ExFsOmpIyA4Z6A8Eyuq1t9TudZhhonT+6o7Or0Ve3PP8qh84HJuE7GFcT0gNAC z7iVVXDnPqrPjkYxEZe/ =tY82 -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
On Mar 4, 2014 2:49 AM, "Dmitry Batiyevskiy" wrote: > > Howard, > My connector config is the following (i've already posted that): > > 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" /> > Okay, thanks. > 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? > Chris recommended NIO. I'll let him answer your question. > Regards, > > Dmitry Batiyevskiy > > Ardas Group Inc. > > www.ardas.dp.ua > > > 2014-03-04 2:04 GMT+02:00 Howard W. Smith, Jr. : > > > On Mon, Mar 3, 2014 at 11:22 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > > Dmitry, > > > > > > On 3/3/14, 6:06 AM, Dmitry Batiyevskiy wrote: > > > > Can you advice how we can find the problem in app/environment like > > > > this? What are possible ways to debug this? > > > > > > Honestly, I'd try switching to the NIO connector and resume your > > > testing. If all is well, it may point to a bug in the APR connector > > > and/or tcnative itself. If you are having similar problems with the > > > pure-Java connectors, then the problem is likely something you are > > > doing in your application that is causing an invalid state. You'll > > > probably get better information from the Java stack trace than from an > > > assertion-failure. > > > > > > Give that a try and let us know how things go. > > > > > > +1 Chris > > > > I have found much /continued/ success using NIO connector across tomcat and > > atmosphere versions. > >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Howard, My connector config is the following (i've already posted that): 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? Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-03-04 2:04 GMT+02:00 Howard W. Smith, Jr. : > On Mon, Mar 3, 2014 at 11:22 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > Dmitry, > > > > On 3/3/14, 6:06 AM, Dmitry Batiyevskiy wrote: > > > Can you advice how we can find the problem in app/environment like > > > this? What are possible ways to debug this? > > > > Honestly, I'd try switching to the NIO connector and resume your > > testing. If all is well, it may point to a bug in the APR connector > > and/or tcnative itself. If you are having similar problems with the > > pure-Java connectors, then the problem is likely something you are > > doing in your application that is causing an invalid state. You'll > > probably get better information from the Java stack trace than from an > > assertion-failure. > > > > Give that a try and let us know how things go. > > > +1 Chris > > I have found much /continued/ success using NIO connector across tomcat and > atmosphere versions. >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Mon, Mar 3, 2014 at 11:22 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Dmitry, > > On 3/3/14, 6:06 AM, Dmitry Batiyevskiy wrote: > > Can you advice how we can find the problem in app/environment like > > this? What are possible ways to debug this? > > Honestly, I'd try switching to the NIO connector and resume your > testing. If all is well, it may point to a bug in the APR connector > and/or tcnative itself. If you are having similar problems with the > pure-Java connectors, then the problem is likely something you are > doing in your application that is causing an invalid state. You'll > probably get better information from the Java stack trace than from an > assertion-failure. > > Give that a try and let us know how things go. +1 Chris I have found much /continued/ success using NIO connector across tomcat and atmosphere versions.
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Howard, On 3/3/14, 10:09 AM, Howard W. Smith, Jr. wrote: > On Mon, Mar 3, 2014 at 6:41 AM, Dmitry Batiyevskiy < > dmitry.batiyevs...@ardas.dp.ua> wrote: > >> org.atmosphere.useNative >> true >> > > also, i wonder what your test results will be if you comment out > the lines above from your web.xml. Probably not... it's unlikely that Atmosphere knows anything about Tomcat's native capabilities. It's definitely tcnative that is throwing that assertion error. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFKyEAAoJEBzwKT+lPKRYFTYP/jWHZIEjSHHkmhIHvul/uAId O/6fQd44mfgjKgs6ykRPEt8HjZoiNWI8SKkjH86f13l0DGFE9/s9eLqPAj3m+MOt F3Q4uP32PDwMmZkd8tpq6CygunEtgOFNuUjwoj34dv0Fpuas1WoHJndIjpuzhGcb sksshvwtG9g56hxCG70bcy8CvoXbVc43CEb1ioOZ2s1fJi7R+C4Ft17s6EsYiICq 974bqDJziYbueDIjhL85tlr6+pHCXB/+7WZqOyFuhivqt42LPMC5HQajmLm/wwxo IfY4Fk+wYiQNKyQ9iffpvlbzoyxkDxrhyQq2Ly3ZO42bZM6JHLVU24KYt1aao0iR jdkS4YO4J5OEASnD8vpWKmVyTE+lB13Ef+cfDrd3VTQi8AbwyPqdEymiV1Ol8r9+ 9f+ZS4PzikjSDdF6A/ZMf8ul4r237Gu/a3wySbEnu0ygBAnJ3qEK4ll7D2UoLZdr wVOaorKLmXb8amEW0BFaFz1zsXpeaO45uClLQV8SJU5E9F+2nOWFPFx171vh8X5e WvCWqN+1ybbVLE/0sTj/ZxX5Uy32j05VnClKmuI9sBGeNEWVEWoLxlwpNmxSLY7G s0f+VkHik+7UjjCBiqi2CTI5kM3mjmvF+JgOEn1M51dJsLGaV8Mte/vWfg9IHabG oCwEyMv5s1WWr9rIj6ug =yqIe -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 Dmitry, On 3/3/14, 6:06 AM, Dmitry Batiyevskiy wrote: > Can you advice how we can find the problem in app/environment like > this? What are possible ways to debug this? Honestly, I'd try switching to the NIO connector and resume your testing. If all is well, it may point to a bug in the APR connector and/or tcnative itself. If you are having similar problems with the pure-Java connectors, then the problem is likely something you are doing in your application that is causing an invalid state. You'll probably get better information from the Java stack trace than from an assertion-failure. Give that a try and let us know how things go. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFKw/AAoJEBzwKT+lPKRY/hYP/RCK/AGsDHLUK6kiEON/m0jL C+32enJUz/p8xhWNGA9HpwjcwZmIW7fDNCQRiBBTs2bodtLW+//z5YTIvUPNM9Bq 9cCX25I+Z/2Dz4ZHfByeRXDNqhViPWhfjfKqAfxM0HSCKuRWF0w7ejUtN4w7bciM nTLG3rWG4HmhmSMfPIIzP0S48tzdXoriUPneMB6s1+h88uP1qvXB8XEsiXWCRaVN TLs5EaE6GksXj/LhpAkJh5HnD9yDxMklYl7soRHkogvenOOPQtMgD/5LnuxO2Ug9 FDQQuWLh6WYm5tPwSmPbcIaWsm/2xkEdCjtk1i9jrZxKKjGk+xWaaHp2ZNnxf/cr KPT94czieYlVc664NVM6OafnpUrVxZXQMuICCtaFqcnkFvOGja/TDr1FObEvkgNz JLUkDoB9NfPpQwQc5r3JF0L0IBAmM+WVOOv9GfmN8PdEIfvN2f4WPwQ5Ya9ExTJV Q70IkiKJBQ7OLpesIZOGqA4AHlGrhLMoMDAjfs9J6tVNSdMLpjGGIrOh60ka9oKb klYfsagEq0gqdgv9M2T4m91mbjwbWo+X+aBv0q7QtL+6vod449ybToXEzQ11CP3s +sU+6crBzUIUTIXu2JR3AGNKjUmIFYRwViiDa6l/MLu7fZGS9z9je6nduaZlJZ82 l6iV0qfUlrPKHyXm/b7v =8Q5O -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
On Mon, Mar 3, 2014 at 6:41 AM, Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua> wrote: > > org.atmosphere.useNative > true > > also, i wonder what your test results will be if you comment out the lines above from your web.xml.
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Mon, Mar 3, 2014 at 9:52 AM, Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua> wrote: > Thanks, I will try updating atmosphere and/or changing maxProcessingThreads > may not be completely related, but what is your maxThreads value in your in server.xml ? mine is below (found in tomee/conf/server.xml) > > Regards, > > Dmitry Batiyevskiy > > Ardas Group Inc. > > www.ardas.dp.ua > > > 2014-03-03 16:33 GMT+02:00 Howard W. Smith, Jr. : > > > On Mon, Mar 3, 2014 at 6:41 AM, Dmitry Batiyevskiy < > > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > > > Atmosphere dependencies from pom.xml: > > > > > > > > > org.atmosphere.extensions > > > atmosphere-gwt20-server > > > 2.0.2 > > > > > > > > > > > > org.atmosphere > > > atmosphere-runtime > > > 2.0.5 > > > > > > > > > > Looks good, but have you tried latest version (Atmosphere 2.1.0 runtime) > ? > > I don't know the appropriate 'gwt' version to use with Atmosphere 2.1.0 > > runtime. I think you can search the atmosphere wiki or mail list, or > post a > > mail there. > > > > I know that Atmosphere 2.0.3 had specific changes/fixes that were in-line > > with Tomcat 7.0.42, which supports your report that 7.0.42 is working (as > > expected). > > > > > > > > > > Dependencies are in war file > > > > > > > okay. > > > > > > > > > > Atmosphere config from web.xml: > > > > > > > > > AtmosphereServlet > > > AtmosphereServlet > > > org.atmosphere.cpr.AtmosphereServlet > > > 1 > > > true > > > > > > > > > > okay, good, i was looking for the async-supported to be set, since you're > > using servlet 3.0. > > > > > > > org.atmosphere.cpr.AtmosphereInterceptor > > > > > > > > > com.mycompany.communicationengine.interceptor.SecurityContextInterceptor > > > > > > > > > > > > org.atmosphere.cpr.packages > > > com.mycompany.atm > > > > > > > > > org.atmosphere.useNative > > > true > > > > > > > > > > > > > > > > > > > > > > > > > > org.atmosphere.cpr.broadcaster.maxProcessingThreads > > > 30 > > > > > > > > > > > > > > > org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads > > > 30 > > > > > > > > > > > > > > > > > Jeanfrancois advised me to accept the default config/settings (for > > maxProcessingThreads and maxAsyncWriteThreads) instead of specifying low > > values like you have (30). what happens when you comment out these > > (atmosphere config) lines from your web.xml when using tomcat 7.0.50? > > > > maybe someone here on tomcat list can advise why your max threads > settings > > is working with tomcat 7.0.42, but not with tomcat 7.0.50. > > > > > > > > > > This is top of web.xml: > > > > > > http://java.sun.com/xml/ns/javaee"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > > > http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; > > > version="3.0"> > > > > > > > > okay, good. > > > > > > > > > > Regards, > > > > > > Dmitry Batiyevskiy > > > > > > Ardas Group Inc. > > > > > > www.ardas.dp.ua > > > > > > > > > 2014-03-03 13:28 GMT+02:00 Howard W. Smith, Jr. < > smithh032...@gmail.com > > >: > > > > > > > On Mon, Mar 3, 2014 at 6:26 AM, Howard W. Smith, Jr. < > > > > smithh032...@gmail.com > > > > > wrote: > > > > > > > > > > > > > > On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < > > > > > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > > > > > > > >> We have upgraded tomcat 7.0.42 to 7.0.50 > > > > >> We have an app which is built around atmosphere framework and uses > > > > >> websockets > > > > >> After upgrade tomcat instance which has only this app dies in few > > > hours > > > > >> after deploy (the whole java process dies) > > > > >> > > > > > > > > > > How did you configure atmosphere? > > > > > > > > > > which version of atmosphere are you using? > > > > > > > > > > can you share your web.xml (atmosphere config)? > > > > > > > > > > which atmosphere-related dependencies? > > > > > > > > > > is atmosphere-related dependencies in tomcat/lib or in your WAR > file? > > > > > > > > > > > > > > also, are you specifying servlet 3.0 (or 2.5) in your web.xml? can > you > > > > copy/paste that config as well? > > > > > > > > > >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Thanks, I will try updating atmosphere and/or changing maxProcessingThreads Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-03-03 16:33 GMT+02:00 Howard W. Smith, Jr. : > On Mon, Mar 3, 2014 at 6:41 AM, Dmitry Batiyevskiy < > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > Atmosphere dependencies from pom.xml: > > > > > > org.atmosphere.extensions > > atmosphere-gwt20-server > > 2.0.2 > > > > > > > > org.atmosphere > > atmosphere-runtime > > 2.0.5 > > > > > > Looks good, but have you tried latest version (Atmosphere 2.1.0 runtime) ? > I don't know the appropriate 'gwt' version to use with Atmosphere 2.1.0 > runtime. I think you can search the atmosphere wiki or mail list, or post a > mail there. > > I know that Atmosphere 2.0.3 had specific changes/fixes that were in-line > with Tomcat 7.0.42, which supports your report that 7.0.42 is working (as > expected). > > > > > > Dependencies are in war file > > > > okay. > > > > > > Atmosphere config from web.xml: > > > > > > AtmosphereServlet > > AtmosphereServlet > > org.atmosphere.cpr.AtmosphereServlet > > 1 > > true > > > > > > okay, good, i was looking for the async-supported to be set, since you're > using servlet 3.0. > > > > org.atmosphere.cpr.AtmosphereInterceptor > > > > > com.mycompany.communicationengine.interceptor.SecurityContextInterceptor > > > > > > > > org.atmosphere.cpr.packages > > com.mycompany.atm > > > > > > org.atmosphere.useNative > > true > > > > > > > > > > > > > > > org.atmosphere.cpr.broadcaster.maxProcessingThreads > > 30 > > > > > > > > > org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads > > 30 > > > > > > > > > > Jeanfrancois advised me to accept the default config/settings (for > maxProcessingThreads and maxAsyncWriteThreads) instead of specifying low > values like you have (30). what happens when you comment out these > (atmosphere config) lines from your web.xml when using tomcat 7.0.50? > > maybe someone here on tomcat list can advise why your max threads settings > is working with tomcat 7.0.42, but not with tomcat 7.0.50. > > > > > > This is top of web.xml: > > > > http://java.sun.com/xml/ns/javaee"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > > http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; > > version="3.0"> > > > > > okay, good. > > > > > > Regards, > > > > Dmitry Batiyevskiy > > > > Ardas Group Inc. > > > > www.ardas.dp.ua > > > > > > 2014-03-03 13:28 GMT+02:00 Howard W. Smith, Jr. >: > > > > > On Mon, Mar 3, 2014 at 6:26 AM, Howard W. Smith, Jr. < > > > smithh032...@gmail.com > > > > wrote: > > > > > > > > > > > On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < > > > > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > > > > > >> We have upgraded tomcat 7.0.42 to 7.0.50 > > > >> We have an app which is built around atmosphere framework and uses > > > >> websockets > > > >> After upgrade tomcat instance which has only this app dies in few > > hours > > > >> after deploy (the whole java process dies) > > > >> > > > > > > > > How did you configure atmosphere? > > > > > > > > which version of atmosphere are you using? > > > > > > > > can you share your web.xml (atmosphere config)? > > > > > > > > which atmosphere-related dependencies? > > > > > > > > is atmosphere-related dependencies in tomcat/lib or in your WAR file? > > > > > > > > > > > also, are you specifying servlet 3.0 (or 2.5) in your web.xml? can you > > > copy/paste that config as well? > > > > > >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Mon, Mar 3, 2014 at 6:41 AM, Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua> wrote: > Atmosphere dependencies from pom.xml: > > > org.atmosphere.extensions > atmosphere-gwt20-server > 2.0.2 > > > > org.atmosphere > atmosphere-runtime > 2.0.5 > > Looks good, but have you tried latest version (Atmosphere 2.1.0 runtime) ? I don't know the appropriate 'gwt' version to use with Atmosphere 2.1.0 runtime. I think you can search the atmosphere wiki or mail list, or post a mail there. I know that Atmosphere 2.0.3 had specific changes/fixes that were in-line with Tomcat 7.0.42, which supports your report that 7.0.42 is working (as expected). > > Dependencies are in war file > okay. > > Atmosphere config from web.xml: > > > AtmosphereServlet > AtmosphereServlet > org.atmosphere.cpr.AtmosphereServlet > 1 > true > > okay, good, i was looking for the async-supported to be set, since you're using servlet 3.0. > org.atmosphere.cpr.AtmosphereInterceptor > > com.mycompany.communicationengine.interceptor.SecurityContextInterceptor > > > > org.atmosphere.cpr.packages > com.mycompany.atm > > > org.atmosphere.useNative > true > > > > > org.atmosphere.cpr.broadcaster.maxProcessingThreads > 30 > > > > org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads > 30 > > > Jeanfrancois advised me to accept the default config/settings (for maxProcessingThreads and maxAsyncWriteThreads) instead of specifying low values like you have (30). what happens when you comment out these (atmosphere config) lines from your web.xml when using tomcat 7.0.50? maybe someone here on tomcat list can advise why your max threads settings is working with tomcat 7.0.42, but not with tomcat 7.0.50. > > This is top of web.xml: > > http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; > version="3.0"> > > okay, good. > > Regards, > > Dmitry Batiyevskiy > > Ardas Group Inc. > > www.ardas.dp.ua > > > 2014-03-03 13:28 GMT+02:00 Howard W. Smith, Jr. : > > > On Mon, Mar 3, 2014 at 6:26 AM, Howard W. Smith, Jr. < > > smithh032...@gmail.com > > > wrote: > > > > > > > > On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < > > > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > > > >> We have upgraded tomcat 7.0.42 to 7.0.50 > > >> We have an app which is built around atmosphere framework and uses > > >> websockets > > >> After upgrade tomcat instance which has only this app dies in few > hours > > >> after deploy (the whole java process dies) > > >> > > > > > > How did you configure atmosphere? > > > > > > which version of atmosphere are you using? > > > > > > can you share your web.xml (atmosphere config)? > > > > > > which atmosphere-related dependencies? > > > > > > is atmosphere-related dependencies in tomcat/lib or in your WAR file? > > > > > > > > also, are you specifying servlet 3.0 (or 2.5) in your web.xml? can you > > copy/paste that config as well? > > >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Atmosphere dependencies from pom.xml: org.atmosphere.extensions atmosphere-gwt20-server 2.0.2 org.atmosphere atmosphere-runtime 2.0.5 Dependencies are in war file Atmosphere config from web.xml: AtmosphereServlet AtmosphereServlet org.atmosphere.cpr.AtmosphereServlet 1 true org.atmosphere.cpr.AtmosphereInterceptor com.mycompany.communicationengine.interceptor.SecurityContextInterceptor org.atmosphere.cpr.packages com.mycompany.atm org.atmosphere.useNative true org.atmosphere.cpr.broadcaster.maxProcessingThreads 30 org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads 30 This is top of web.xml: http://java.sun.com/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; version="3.0"> Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-03-03 13:28 GMT+02:00 Howard W. Smith, Jr. : > On Mon, Mar 3, 2014 at 6:26 AM, Howard W. Smith, Jr. < > smithh032...@gmail.com > > wrote: > > > > > On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < > > dmitry.batiyevs...@ardas.dp.ua> wrote: > > > >> We have upgraded tomcat 7.0.42 to 7.0.50 > >> We have an app which is built around atmosphere framework and uses > >> websockets > >> After upgrade tomcat instance which has only this app dies in few hours > >> after deploy (the whole java process dies) > >> > > > > How did you configure atmosphere? > > > > which version of atmosphere are you using? > > > > can you share your web.xml (atmosphere config)? > > > > which atmosphere-related dependencies? > > > > is atmosphere-related dependencies in tomcat/lib or in your WAR file? > > > > > also, are you specifying servlet 3.0 (or 2.5) in your web.xml? can you > copy/paste that config as well? >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Mon, Mar 3, 2014 at 6:26 AM, Howard W. Smith, Jr. wrote: > > On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < > dmitry.batiyevs...@ardas.dp.ua> wrote: > >> We have upgraded tomcat 7.0.42 to 7.0.50 >> We have an app which is built around atmosphere framework and uses >> websockets >> After upgrade tomcat instance which has only this app dies in few hours >> after deploy (the whole java process dies) >> > > How did you configure atmosphere? > > which version of atmosphere are you using? > > can you share your web.xml (atmosphere config)? > > which atmosphere-related dependencies? > > is atmosphere-related dependencies in tomcat/lib or in your WAR file? > > also, are you specifying servlet 3.0 (or 2.5) in your web.xml? can you copy/paste that config as well?
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
On Thu, Feb 20, 2014 at 11:00 AM, Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua> wrote: > We have upgraded tomcat 7.0.42 to 7.0.50 > We have an app which is built around atmosphere framework and uses > websockets > After upgrade tomcat instance which has only this app dies in few hours > after deploy (the whole java process dies) > How did you configure atmosphere? which version of atmosphere are you using? can you share your web.xml (atmosphere config)? which atmosphere-related dependencies? is atmosphere-related dependencies in tomcat/lib or in your WAR file?
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Can you advice how we can find the problem in app/environment like this? What are possible ways to debug this? Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-02-27 23:24 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dmitry, > > On 2/27/14, 3:27 PM, Dmitry Batiyevskiy wrote: > > This didn't helped, java process died with same error in about 5 > > hours > > Okay. The assert() call will in fact kill the process -- I had to check. > It seems that for the time being, your only resource would be to switch > to one of the pure-Java connectors until you are able to track-down the > problem. > > We haven't been hearing a lot about this problem, so it looks like for > now it's likely to be a problem with your application or environment. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTD60NAAoJEBzwKT+lPKRY8YEQAIFCUrgNaLwRgA1ktIyOwid/ > bU/9CD93obj/vgsQbUkoDB4wneepGW5AFWVR0kk5tVWynjjg8JZNbiKtYoHX5FrJ > Ig4hzzlUaETL/KNczeMwprmhARZSdMEl+QXXi9Evau/K7ngCUZUXGV8nTrCTGxtz > XEmXp/UnSkRDKuD72TkYMFWNQhiZZjLBeqcba6B0SY80F0jj04r5yNW7dLDmNphx > LUC+U6WtPyoo3IMj7V5KRTPcDTmjDsGIjp//lCf7kDZ9GyQTHasV85GBzxmuwvvj > TeuD17cjOsOacEw4baxqI/ah1IboWkVHhdwEn/7Af6iUS+AI2J5lQmMej/DoZiJy > y805A+xDTOap29vhZTx9d+PlTQnp0KCnHKfN8sRHBtQGdImarr8bQ9E5KI1GEiaP > ezYRiM0Z0sA+sCq7dUMvFEjXXsNcoP1kInq3HjqRdaJd2LE6peRYDzJhPgXB3U22 > NZSF6i4Ab8mSuueTQvX7UOhZG8s4chMdfcmw/W9e8lMG43MKkiuELHENzLarQwKe > 6hOk6eUthYw1p1zSO53UxwgGAzC7yLAPQ/tvDZN1dbewUcOWNjQ9GzIDZ2WMTZRg > TsGFz3CjmSo59q9VegmIA4DHMRXz0Zxrxzt2YjQEwXSYMoVAm8vcM3AssuorhAWi > HCcozZP3IkQHc7eBZ2lW > =xTw7 > -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 Dmitry, On 2/27/14, 3:27 PM, Dmitry Batiyevskiy wrote: > This didn't helped, java process died with same error in about 5 > hours Okay. The assert() call will in fact kill the process -- I had to check. It seems that for the time being, your only resource would be to switch to one of the pure-Java connectors until you are able to track-down the problem. We haven't been hearing a lot about this problem, so it looks like for now it's likely to be a problem with your application or environment. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTD60NAAoJEBzwKT+lPKRY8YEQAIFCUrgNaLwRgA1ktIyOwid/ bU/9CD93obj/vgsQbUkoDB4wneepGW5AFWVR0kk5tVWynjjg8JZNbiKtYoHX5FrJ Ig4hzzlUaETL/KNczeMwprmhARZSdMEl+QXXi9Evau/K7ngCUZUXGV8nTrCTGxtz XEmXp/UnSkRDKuD72TkYMFWNQhiZZjLBeqcba6B0SY80F0jj04r5yNW7dLDmNphx LUC+U6WtPyoo3IMj7V5KRTPcDTmjDsGIjp//lCf7kDZ9GyQTHasV85GBzxmuwvvj TeuD17cjOsOacEw4baxqI/ah1IboWkVHhdwEn/7Af6iUS+AI2J5lQmMej/DoZiJy y805A+xDTOap29vhZTx9d+PlTQnp0KCnHKfN8sRHBtQGdImarr8bQ9E5KI1GEiaP ezYRiM0Z0sA+sCq7dUMvFEjXXsNcoP1kInq3HjqRdaJd2LE6peRYDzJhPgXB3U22 NZSF6i4Ab8mSuueTQvX7UOhZG8s4chMdfcmw/W9e8lMG43MKkiuELHENzLarQwKe 6hOk6eUthYw1p1zSO53UxwgGAzC7yLAPQ/tvDZN1dbewUcOWNjQ9GzIDZ2WMTZRg TsGFz3CjmSo59q9VegmIA4DHMRXz0Zxrxzt2YjQEwXSYMoVAm8vcM3AssuorhAWi HCcozZP3IkQHc7eBZ2lW =xTw7 -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
This didn't helped, java process died with same error in about 5 hours Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-02-21 19:50 GMT+02:00 Dmitry Batiyevskiy < dmitry.batiyevs...@ardas.dp.ua>: > Ok thanks I will try setting org.apache.catalina.connector.RECYCLE_FACADES > to true > > > Regards, > > Dmitry Batiyevskiy > > Ardas Group Inc. > > www.ardas.dp.ua > >
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
Ok thanks I will try setting org.apache.catalina.connector.RECYCLE_FACADES to true Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dmitry, On 2/21/14, 11:17 AM, Dmitry Batiyevskiy wrote: > 2014-02-21 18:10 GMT+02:00 Christopher Schultz > > : > > Dmitry, > > On 2/20/14, 1:58 PM, Dmitry Batiyevskiy wrote: When using tomcat 7.0.42 I used libtcnative 1.1.24-1 which comes from debian repos Upgrade to tomcat 7.0.50 required upgrade of libtcnative also and there was no updated version in debian repos so I had to compile it from source tarball downloaded here http://tomcat.apache.org/download-native.cgi Downgrading tomcat also means downgrading libtcnative for me > > Tomcat 7.0.50 ships with tcnative 1.1.29, which is the current > latest version, and is required by Tomcat 7.0.50 (that is, you > can't downgrade tcnative and stick with Tomcat 7.0.50). > > >> I am using tcnative 1.1.29 with tomcat 7.0.50, see log file And >> I am downgrading tcnative when downgrading tomcat to 7.0.42 > > Connector configuration: >>> maxHttpHeaderSize="8192" maxThreads="15000" enableLookups="false" disableUploadTimeout="true" acceptCount="1000" scheme="https" secure="true" SSLEnabled="true" compression="off" SSLCertificateFile="/opt/tomcat/my.crt" SSLCertificateKeyFile="/opt/tomcat/my.key" /> > > I would normally suggest that you set the system property > org.apache.catalina.connector. RECYCLE_FACADES to "true", but I'm > not sure it would help you in this case. It's worth trying: it may > help you determine whether you have a resource leak due to storing > a request or response object longer than appropriate, but I > suspect you'll still get the same error. > > Does the process die immediately after the assertion failure? Do > you get a core file and/or Java dump or anything like that? > > >> No dumps or core files are created. I am not sure if java process >> dies immediately, assertion failed message does not contains >> timestamp When monitoring reports my app does not work I log into >> server in few minutes and there is no java process, last message >> in log is assertion failed and no other errors/warnings before >> that Try setting that system property to see if it helps at all. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTB45YAAoJEBzwKT+lPKRYa8QQAL41/U9w3qyOv1lA7H/iQf92 MRAr3xuKUApjskE4BFPyHUnqv99xtjBIAqnPYn8NNwc+ps7aUzewWPs0PU9n5Re5 5uaIwV/xxozzEPzOKDwQxlBugU+ezh5FZlDb2Y7fQnnO6iMbl8ScmO7ul/1BCTwb Be9NmFKCDx9bOOXqK0Atfxd6ALXRXiCIHjIGXzHtvsqqW3kHH1O9nmS+yETWB6Ho /ZP8YM9Sr8tmHBaE9YybJISYwCfODu/G5IMBi2PvBl9Sf7x0HUzxp2yju9HyG9bH 7biFHG9GhU/KqhulgZyC+m4Ye3XmZajCC1zvo10CSxF/3/aEkEhXqMnVezjfGwkv xYkD/0I1CSFNIpNYqaPkXTAe+5NLHIjFdVsbaOxQ77CecfV46iBH0gXqD30kPaFZ Qo3J9Nim4OZRr2kmGvQsneiF8SZUT+v4BN9wySXBs21Dl2JIlOTWlcvMBj1qCE22 U14Xg2wiX+LiEgLWdn65GSPZaqxFc56UmiMoBqUbo6LErUJAnOwja9LgnqU0R0Dq knbpyBrMNHfFsaliHVZuVEcCtNjs4oF3+/vBACG0cFSwUTCHudkJmtTKjWldGs8z XJtwK0fsnayw270+BPy/YgPX2PcnTOP+4uFpUbNmlE33CmKoHTc/KAGccJIKlMRj pegkiOrFUlR8fk+dl3Cq =7gZz -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
2014-02-21 18:10 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dmitry, > > On 2/20/14, 1:58 PM, Dmitry Batiyevskiy wrote: > > When using tomcat 7.0.42 I used libtcnative 1.1.24-1 which comes > > from debian repos Upgrade to tomcat 7.0.50 required upgrade of > > libtcnative also and there was no updated version in debian repos > > so I had to compile it from source tarball downloaded here > > http://tomcat.apache.org/download-native.cgi Downgrading tomcat > > also means downgrading libtcnative for me > > Tomcat 7.0.50 ships with tcnative 1.1.29, which is the current latest > version, and is required by Tomcat 7.0.50 (that is, you can't > downgrade tcnative and stick with Tomcat 7.0.50). > I am using tcnative 1.1.29 with tomcat 7.0.50, see log file And I am downgrading tcnative when downgrading tomcat to 7.0.42 > > > Connector configuration: > maxHttpHeaderSize="8192" maxThreads="15000" enableLookups="false" > > disableUploadTimeout="true" acceptCount="1000" scheme="https" > > secure="true" SSLEnabled="true" compression="off" > > SSLCertificateFile="/opt/tomcat/my.crt" > > SSLCertificateKeyFile="/opt/tomcat/my.key" /> > > I would normally suggest that you set the system property > org.apache.catalina.connector. RECYCLE_FACADES to "true", but I'm not > sure it would help you in this case. It's worth trying: it may help > you determine whether you have a resource leak due to storing a > request or response object longer than appropriate, but I suspect > you'll still get the same error. > > Does the process die immediately after the assertion failure? Do you > get a core file and/or Java dump or anything like that? > No dumps or core files are created. I am not sure if java process dies immediately, assertion failed message does not contains timestamp When monitoring reports my app does not work I log into server in few minutes and there is no java process, last message in log is assertion failed and no other errors/warnings before that > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTB3pwAAoJEBzwKT+lPKRYJhQP/2EiaoB7dTqZDVDRnn2DYWYX > /ml6zal7iv5e3wFYjiz6WCdsoBJ6dx0ZbNNhZUz/oUdm7Axo5QMwzjBOogE0sZdZ > +gKfLieKE7F3Xg4hsOB5XYiawATsJUhu6vjNJe08wcs0w+EDtna8u5jVAozjS3s/ > +EAHpmAjk0jahfK6e3UKGFSFmVYG5jNmtCiue0YA8nlhWaytkgi+A/mJ1l/geCA2 > NXFNHhqipeUEvZP94XVseGjG77rtxENRxVELxmW48f3ZLxORfXXFzs4AgqyXyrcM > sNK0LfaaNZi/z2W+p8gU5btq8LdZXBKGugVKQ/XspHO4EzuZ9T0Yntg4dAPLB/af > 7c8gan4cPxoUybW/vF+bS9kD2Cb8lbSUjonLk/XPRp899reOROX73AC6mMm3MOAq > b4yjpoqZPswKK91R2R4n97Tf1Wx4u4B/anay8Mr+x/6Ki3kq7VZvrYZd2icdxqmq > CetH/yJ+awx5nYM6FMSsJN1/py+pMswc3WFVdUkjkpx7+qnllUj+4CDPWaPl435j > s15XK6ftKh5XZTSwsHQXmL4ZGVvp4zd+c31VRWAoI/FTn0wChAJVzsCiwcsk1cFw > +dz5EFL3fEf2mnRxLRVFIhgHUlIFN8CkDil0/d+SN+FKIeq0xTkk6wbwpoL/LmQl > oMY1JMR+ULa0MRNlqbN0 > =jrun > -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 Dmitry, On 2/20/14, 1:58 PM, Dmitry Batiyevskiy wrote: > When using tomcat 7.0.42 I used libtcnative 1.1.24-1 which comes > from debian repos Upgrade to tomcat 7.0.50 required upgrade of > libtcnative also and there was no updated version in debian repos > so I had to compile it from source tarball downloaded here > http://tomcat.apache.org/download-native.cgi Downgrading tomcat > also means downgrading libtcnative for me Tomcat 7.0.50 ships with tcnative 1.1.29, which is the current latest version, and is required by Tomcat 7.0.50 (that is, you can't downgrade tcnative and stick with Tomcat 7.0.50). > Connector configuration: maxHttpHeaderSize="8192" maxThreads="15000" enableLookups="false" > disableUploadTimeout="true" acceptCount="1000" scheme="https" > secure="true" SSLEnabled="true" compression="off" > SSLCertificateFile="/opt/tomcat/my.crt" > SSLCertificateKeyFile="/opt/tomcat/my.key" /> I would normally suggest that you set the system property org.apache.catalina.connector. RECYCLE_FACADES to "true", but I'm not sure it would help you in this case. It's worth trying: it may help you determine whether you have a resource leak due to storing a request or response object longer than appropriate, but I suspect you'll still get the same error. Does the process die immediately after the assertion failure? Do you get a core file and/or Java dump or anything like that? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTB3pwAAoJEBzwKT+lPKRYJhQP/2EiaoB7dTqZDVDRnn2DYWYX /ml6zal7iv5e3wFYjiz6WCdsoBJ6dx0ZbNNhZUz/oUdm7Axo5QMwzjBOogE0sZdZ +gKfLieKE7F3Xg4hsOB5XYiawATsJUhu6vjNJe08wcs0w+EDtna8u5jVAozjS3s/ +EAHpmAjk0jahfK6e3UKGFSFmVYG5jNmtCiue0YA8nlhWaytkgi+A/mJ1l/geCA2 NXFNHhqipeUEvZP94XVseGjG77rtxENRxVELxmW48f3ZLxORfXXFzs4AgqyXyrcM sNK0LfaaNZi/z2W+p8gU5btq8LdZXBKGugVKQ/XspHO4EzuZ9T0Yntg4dAPLB/af 7c8gan4cPxoUybW/vF+bS9kD2Cb8lbSUjonLk/XPRp899reOROX73AC6mMm3MOAq b4yjpoqZPswKK91R2R4n97Tf1Wx4u4B/anay8Mr+x/6Ki3kq7VZvrYZd2icdxqmq CetH/yJ+awx5nYM6FMSsJN1/py+pMswc3WFVdUkjkpx7+qnllUj+4CDPWaPl435j s15XK6ftKh5XZTSwsHQXmL4ZGVvp4zd+c31VRWAoI/FTn0wChAJVzsCiwcsk1cFw +dz5EFL3fEf2mnRxLRVFIhgHUlIFN8CkDil0/d+SN+FKIeq0xTkk6wbwpoL/LmQl oMY1JMR+ULa0MRNlqbN0 =jrun -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
When using tomcat 7.0.42 I used libtcnative 1.1.24-1 which comes from debian repos Upgrade to tomcat 7.0.50 required upgrade of libtcnative also and there was no updated version in debian repos so I had to compile it from source tarball downloaded here http://tomcat.apache.org/download-native.cgi Downgrading tomcat also means downgrading libtcnative for me Connector configuration: limits.conf is appropriate for this number of threads, however on production server we never had more than 2000 active established connections First lines of log when starting tomcat: Feb 18, 2014 9:12:50 AM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.29 using APR version 1.4.6. Feb 18, 2014 9:12:50 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Feb 18, 2014 9:12:51 AM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized (OpenSSL 1.0.1e 11 Feb 2013) Feb 18, 2014 9:12:51 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-apr-8080"] Feb 18, 2014 9:12:51 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-apr-8443"] Feb 18, 2014 9:12:51 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["ajp-apr-8009"] Feb 18, 2014 9:12:51 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1188 ms Feb 18, 2014 9:12:51 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service dbApp Feb 18, 2014 9:12:51 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.50 Feb 18, 2014 9:12:51 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Feb 18, 2014 9:12:51 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.50 Feb 18, 2014 9:12:51 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /opt/tomcat/webapps/somemyapp.war Feb 18, 2014 9:13:39 AM org.apache.catalina.util.SessionIdGenerator createSecureRandom INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [7,593] milliseconds. Feb 18, 2014 9:13:39 AM com.radiadesign.catalina.session.PropertiesHolder readRedisSettings INFO: Redis settings setup is finished. Applied values - redisHost: somemyhost, redisPort: 6379, redisDatabase: 0 Feb 18, 2014 9:13:39 AM com.radiadesign.catalina.session.RedisSessionManager startInternal INFO: Attached to RedisSessionHandlerValve Feb 18, 2014 9:13:39 AM com.radiadesign.catalina.session.RedisSessionManager initializeSerializer INFO: Attempting to use serializer :com.radiadesign.catalina.session.JavaSerializer Feb 18, 2014 9:13:39 AM com.radiadesign.catalina.session.RedisSessionManager startInternal INFO: Will expire sessions after 28800 seconds Regards, Dmitry Batiyevskiy Ardas Group Inc. www.ardas.dp.ua 2014-02-20 20:14 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dmitry, > > On 2/20/14, 11:00 AM, Dmitry Batiyevskiy wrote: > > We have upgraded tomcat 7.0.42 to 7.0.50 We have an app which is > > built around atmosphere framework and uses websockets After upgrade > > tomcat instance which has only this app dies in few hours after > > deploy (the whole java process dies) > > > > The only error in log is following: java: src/network.c:441: > > Java_org_apache_tomcat_jni_Socket_send: Assertion `(s->opaque != > > ((void *)0))' failed > > Does the process die immediately after this assertion failure? > > > No memory dumps are created (java process is launched with > > -XX:+HeapDumpOnOutOfMemoryError) and can not find anything like OOM > > killer in system log (we use Debian 7) > > > > Rollback to 7.0.42 helps and app works fine with same configs > > (context.xml, server.xml, etc) and libs We use oracle jdk 1.7.45, > > changing jdk version doesn't helps when using tomcat 7.0.50 > > What version of tcnative are you using? The version bundled with > Tomcat or an external version? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTBkYSAAoJEBzwKT+lPKRYBtQQAKr1p3NfO5BxcKZqwDxhw1Hg > qol9RxOE6JIPkowdHjJdgOg0mNc1ROeG6HFu/aLDiJ0uP34piaiwQRDSgk6/7j0J > lZSplp+fO8gl05Yhb7lzl/Y/+Our21Cu0NkY7GES1McY2yKDQKsLWJJixCD4lEFZ > yS4z4fd6ihSlmpXvkhm7vRNxyvz+zNlCi1/nqt08Ha8UBLqtg4kUDxJEHYlAj8OX > k9+dlzTrJtJgm/2RvSm1RzODA6dETwAsxCLF2eAqVZu2zSSssKDwBvVKRs0FoZ1m > 5S7v4JV2K5EDxgcMw+NR9TUziOAbG17/QXuZuylmcBGhVirwVpx2p/xPw7AF+Jv7 > dsbdWcFRkOQun5w1P0OCe7zwDf8yrZWrt6fGSs1E1gkeAo/kg33ybT8NS1TUKBMN > rAonwH/GCBPJvU4Ukr/h8ISCyVROiPxwKbMi0S2bUkMguk7eXZaMZmw/cA5859d6 > Xpus7IQ0RiMZ4LEq7IosDXahMfE48iY7OG3wcDL2RhsPk3huEc7LWi+wNHzV1xdL > 1VLYAKZvkMYy9Y8
Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dmitry, On 2/20/14, 11:00 AM, Dmitry Batiyevskiy wrote: > We have upgraded tomcat 7.0.42 to 7.0.50 We have an app which is > built around atmosphere framework and uses websockets After upgrade > tomcat instance which has only this app dies in few hours after > deploy (the whole java process dies) > > The only error in log is following: java: src/network.c:441: > Java_org_apache_tomcat_jni_Socket_send: Assertion `(s->opaque != > ((void *)0))' failed Does the process die immediately after this assertion failure? > No memory dumps are created (java process is launched with > -XX:+HeapDumpOnOutOfMemoryError) and can not find anything like OOM > killer in system log (we use Debian 7) > > Rollback to 7.0.42 helps and app works fine with same configs > (context.xml, server.xml, etc) and libs We use oracle jdk 1.7.45, > changing jdk version doesn't helps when using tomcat 7.0.50 What version of tcnative are you using? The version bundled with Tomcat or an external version? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTBkYSAAoJEBzwKT+lPKRYBtQQAKr1p3NfO5BxcKZqwDxhw1Hg qol9RxOE6JIPkowdHjJdgOg0mNc1ROeG6HFu/aLDiJ0uP34piaiwQRDSgk6/7j0J lZSplp+fO8gl05Yhb7lzl/Y/+Our21Cu0NkY7GES1McY2yKDQKsLWJJixCD4lEFZ yS4z4fd6ihSlmpXvkhm7vRNxyvz+zNlCi1/nqt08Ha8UBLqtg4kUDxJEHYlAj8OX k9+dlzTrJtJgm/2RvSm1RzODA6dETwAsxCLF2eAqVZu2zSSssKDwBvVKRs0FoZ1m 5S7v4JV2K5EDxgcMw+NR9TUziOAbG17/QXuZuylmcBGhVirwVpx2p/xPw7AF+Jv7 dsbdWcFRkOQun5w1P0OCe7zwDf8yrZWrt6fGSs1E1gkeAo/kg33ybT8NS1TUKBMN rAonwH/GCBPJvU4Ukr/h8ISCyVROiPxwKbMi0S2bUkMguk7eXZaMZmw/cA5859d6 Xpus7IQ0RiMZ4LEq7IosDXahMfE48iY7OG3wcDL2RhsPk3huEc7LWi+wNHzV1xdL 1VLYAKZvkMYy9Y8MNaVkYWBhtfJ49hbwQLUTGiUM3aewr2KKd5Bjc2OT333hzAtg MxjDANBYHeiFm/iigd/brAlrINDrcP77sDdLC7oZpNkh3McY8zvXr47G7r6mLj1m N8Uv3s0hNqS0BKVsT1G7 =H3cC -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
Dmitry Batiyevskiy wrote: We have upgraded tomcat 7.0.42 to 7.0.50 We have an app which is built around atmosphere framework and uses websockets After upgrade tomcat instance which has only this app dies in few hours after deploy (the whole java process dies) The only error in log is following: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion `(s->opaque != ((void *)0))' failed No memory dumps are created (java process is launched with -XX:+HeapDumpOnOutOfMemoryError) and can not find anything like OOM killer in system log (we use Debian 7) Rollback to 7.0.42 helps and app works fine with same configs (context.xml, server.xml, etc) and libs We use oracle jdk 1.7.45, changing jdk version doesn't helps when using tomcat 7.0.50 Not sure what other details I can provide about this issue The first 20 lines of the Tomcat log, when you start Tomcat. Also maybe your configuration in server.xml. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
