Change socket timeout in server side

[Yin, Ivan]

Hi all,

I am using Tomcat7 and have deployed a web server on it.

Currently the client side is running into the error 
"java.net.SocketTimeoutException: Read timed out" after running the web service 
for one minute.

I understand that this can be set in the client side but I would like to change 
this default value in the server side. Is it possible?

I have found a related page as below:
https://axis.apache.org/axis2/java/core/docs/http-transport.html

Two timeout instances exist in the transport level, Socket timeout and 
Connection timeout. These can be configured either at deployment or run time. 
If configuring at deployment time, the user has to add the following lines in 
axis2.xml.
For Socket timeout:
some_integer_value

According to this , I tried to add this line in the axis2.xml file and restart 
tomcat but it didn't work. Has anyone done this before or is there anything way 
to change it in the server side?

Any comment would be appreciated.

Regards,

Ivan Yin

Product Support, GSC China BI Support Team

SAP Beijing Software System Co., Lt 4/F, DLSP16, International Informat, 116023 
Dalian, China, China

T +86 411 8483-6392, M +86 18842622311, E 
ivan@sap.com

RE: RemoteEndpoint.Async sendText blocking

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: RemoteEndpoint.Async sendText blocking

> When the BIO connector is in use, you end up with weird things like
> this. I would switch to BIO if you want to use async.

Might want to rephrase that...  Presumably Chris meant "switch to NIO".

Note that the BIO connector is removed (yay!) in Tomcat 8.5 and above.

 - Chuck


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


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

Re: RemoteEndpoint.Async sendText blocking

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

To whom it may concern,

On 6/29/17 1:49 PM, V User wrote:
> Yes, although I admit I'm just learning about all the implications
> of that. It seemed to me that even if the actual transmission/write
> blocks indefinitely, that should be happening "asynchronously" in
> another thread or something and shouldn't stop the Async version of
> sendText from returning since it's supposed to return "before the
> message is transmitted". It looks like I was wrong there though, so
> I'll have to look in to change the connector type.

When the BIO connector is in use, you end up with weird things like
this. I would switch to BIO if you want to use async.

Any reason not to upgrade to Tomcat 8.0/8.5? Many improvements...

- -chris

> On Thu, Jun 29, 2017 at 1:39 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Z, V, etc.,
> 
> On 6/29/17 1:16 PM, V User wrote:
 Hello! I have a question about the RemoteEndpoint.Async
 sendText method. The spec states: "Initiates the asynchronous
 transmission of a text message. This method returns before
 the message is transmitted." To me, this implies that the
 method should return immediately regardless of network status
 (i.e. it should still return immediately even if the socket
 connection has died without closing), but I've observed it
 blocking on writes to a broken connection.
 
 I'm also dealing with a known issue with timeouts on Tomcat 7
 with a BIO connector 
 (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304).
 Looking at the source, the Basic/blocking sendText method
 calls sendPartialString, which uses a Future in the same way
 that the Async sendText method does, and then calls get on
 that Future with the configured timeout, so I'd imagine that
 if the Basic/blocking method has broken timeouts then the
 Async timeouts will be broken as well.
 
 Am I mis-interpreting the spec by expecting Async sendText
 to return immediately if the socket connection is broken? Is
 this just an extension of the issue with BIO connectors?
 
 My version information is: Server version: Apache
 Tomcat/7.0.64 Server built:   Aug 19 2015 17:18:06 UTC Server
 number:  7.0.64.0 OS Name:Linux OS Version:
 3.13.0-57-generic Architecture:   amd64 JVM Version:
 1.8.0_131-b11 JVM Vendor: Oracle Corporation
 
 Thanks, Z
> 
> Are you in fact using a BIO connector? Because you can't really
> expect non-blocking semantics with an underlying pro-blocking
> connector.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZVWoNAAoJEBzwKT+lPKRYQrEP/0pmfxg7sjspLNnbvDxTc3Hj
oCmMjiUyUfyWbQfsh1kHh85CJYoZMgsrTl14jOzmwJFDg3wM1vTJHK99W5F6i9qY
3iRfZPAlRTiR19MqkJv5LL2y/QDg2ccIraJgOiXQ+fIKWQUx23cbEzCdbISwFL/p
Gjz5GHc3cpyIHSit9/Hxx8eLUND7P0T57zKpYwyRUVMs6eC0Y67L35tr0DNTUBTv
nHrkZ+mBaiTv7kdeDisc7gQjXganP/WuTkjVWP3XTR1JHEDHRiqRykq5pj/K+Nc8
oyK4LBIcmaN/paHKe9o8zlG+iu2koul9fDX5DxuUJSlnxfg0pOaLxDeC/YzFQrWM
WPVivhtVhB/fVgoT3IFj4jDoYOHMNepBSEek3ACxi92W+b3bM34YRWo5lKunZqo4
xlCeVaOpXYYfZUQPs7Hxv6p7HPTp+uIAXoVcFX8zCyW30v/bjRJU92RIjcsnDOZE
f6Y/RUMB5xejz6A4pwueuLFlSM1Op6FtkyB8HgeS+xNE8xEiVY4RpOfZTbckJ6UL
QGsDn1w8hZDqBtHWqpLtYujltP1mZn3FtM1DpUxFZuOu74WJs3pmL14AmbvEtyEm
ASoWyQ73l8fmzPwZc9suHY8PRqVZ0/q1QzGX9DFC/im8/5mpDfQC5rZbmLp50ic7
hKP7sfB5KRGvaHmpLjcn
=8q1M
-END PGP SIGNATURE-

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

Re: 502 Proxy Error

[Mark Thomas]

On 29/06/17 18:40, TED SPRADLEY wrote:
> I've worked on this for three days and at this point am not sure where to
> begin debugging. 
> 
> I don't know if this is a SSL Cert issue, an Apache Reverse Proxy issue, a
> Tomcat Connector issue or a Tomcat import of the SSL Cert issue.
> 
> Any feedback is much appreciated.



> Configuration files content:
> 
> -- begin virtualhost.conf
> 
>   ServerName www.example.com
>   ServerAlias example.com *.example.com
>   ProxyRequests off
>   ProxyPreserveHost on
>   ProxyPass / http://example.com:8081/
>   ProxyPassReverse / http://example.com:8081/
>   ProxyPass /somecontext  http://example.com:8081/somecontext
>   ProxyPassReverse  /somecontext  http://example.com:8081/somecontext

The above two lines are unnecessary. The previous ProxyPass proxies all
content to Tomcat.

> 
> 
> 
>   ServerName www.exampledefaultdomain.com
>   ServerAlias exampledefaultdomain.com *.exampledefaultdomain.com
> 
> 
> 
>   ServerName www.example.com
>   ServerAlias example.com *.example.com
>   ProxyRequests off
>   ProxyPreserveHost on
>   CustomLog "/etc/httpd/logs/examplessl.log" "%h %l %u %t \"%r\" %>s %b"
>   ErrorLog "/etc/httpd/logs/examplessl_error.log"
>   SSLEngine on
>   SSLProxyEngine on
>   SSLCertificateFile /path/to/certs/example.com.crt
>   SSLCertificateKeyFile /path/to/keys/example.key
>   SSLCertificateChainFile /path/to/certs/ca_bundle.crt
>   ProxyPass / http://example.com:8443/
>   ProxyPassReverse / http://example.com:8443/
>   ProxyPass /somecontext  http://example.com:8443/somecontext
>   ProxyPassReverse  /somecontext  http://example.com:8443/somecontext

The above two lines are unnecessary. The previous ProxyPass proxies all
content to Tomcat.

And here appears to be the problem.

If you are proxying to a secure port on Tomcat then the scheme needs to
be https, not http. i.e.:

ProxyPass/ https://example.com:8443/
ProxyPassReverse / https://example.com:8443/

Well done for proxying http and https separately. Many users proxy them
to the same Tomcat connector and create a bunch of security issues
(which can be avoided with very careful configuration but that often
gets overlooked).

> 
> -- end virtualhost.conf
> 
> -- begin ssl.conf -
> 
>   ErrorLog logs/ssl_error_log
>   TransferLog logs/ssl_access_log
>   LogLevel warn
>   SSLEngine on
>   SSLProtocol all -SSLv2
>   SSLCertificateFile /path/to/certs/example.com.crt
>   SSLCertificateKeyFile /path/to/keys/example.key
>   SSLCACertificateFile /path/to/certs/ca_bundle.crt
> 
> -- end ssl.conf -
> 
> -- begin Tomcat server.xml Connector:
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
> maxThreads="150"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> proxyName="www.example.com"
> proxyPort="443"
> keystoreFile="conf/.keystore"
> clientAuth="false"
> sslProtocol="TLS"
> xpoweredBy="false"
> server="Apache TomEE" />> -- end Tomcat server.xml Connector:

That looks OK on the face of it.

It would have been nice to see the config for the 8001 connector but
that doesn't appear to be relevant to the problem at this point.

Mark

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

Re: RemoteEndpoint.Async sendText blocking

[V User]

Yes, although I admit I'm just learning about all the implications of that.
It seemed to me that even if the actual transmission/write blocks
indefinitely, that should be happening "asynchronously" in another thread
or something and shouldn't stop the Async version of sendText from
returning since it's supposed to return "before the message is
transmitted". It looks like I was wrong there though, so I'll have to look
in to change the connector type.

Thanks!

On Thu, Jun 29, 2017 at 1:39 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Z, V, etc.,
>
> On 6/29/17 1:16 PM, V User wrote:
> > Hello! I have a question about the RemoteEndpoint.Async sendText
> > method. The spec states: "Initiates the asynchronous transmission
> > of a text message. This method returns before the message is
> > transmitted." To me, this implies that the method should return
> > immediately regardless of network status (i.e. it should still
> > return immediately even if the socket connection has died without
> > closing), but I've observed it blocking on writes to a broken
> > connection.
> >
> > I'm also dealing with a known issue with timeouts on Tomcat 7 with
> > a BIO connector
> > (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking at
> > the source, the Basic/blocking sendText method calls
> > sendPartialString, which uses a Future in the same way that the
> > Async sendText method does, and then calls get on that Future with
> > the configured timeout, so I'd imagine that if the Basic/blocking
> > method has broken timeouts then the Async timeouts will be broken
> > as well.
> >
> > Am I mis-interpreting the spec by expecting Async sendText to
> > return immediately if the socket connection is broken? Is this just
> > an extension of the issue with BIO connectors?
> >
> > My version information is: Server version: Apache Tomcat/7.0.64
> > Server built:   Aug 19 2015 17:18:06 UTC Server number:  7.0.64.0
> > OS Name:Linux OS Version: 3.13.0-57-generic
> > Architecture:   amd64 JVM Version:1.8.0_131-b11 JVM Vendor:
> > Oracle Corporation
> >
> > Thanks, Z
>
> Are you in fact using a BIO connector? Because you can't really expect
> non-blocking semantics with an underlying pro-blocking connector.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllVO1AACgkQHPApP6U8
> pFiZshAApYCGkyjEoMBgCcn9p8UI9HU9Psk62dK8AW40COsc+EeRG7ZdJMB0a1Qs
> ajVcN/hwoPzq5Ml1MbWZOoY0qyRPyb0of9e2ZXKi3xX5PpIAe/CJDrnrU9eyzZ9z
> VTNlkTfD7lcAjfgmlNM23daiAbLs1e5teO4fjGrgARWeElK0wJfbeYZvFIQmUY+N
> sYrsegoy5qYoQ9A5pi9x4ZnrJNsokTZ0FJm/HKpZ9lLzvoCOVkqONNZtd/ak+TO4
> 12AQzU2hRzyRmcSwRRJtbMQ6BzoOiTmKcIodlnwDtWkw1DNg6VVOWMTvF7gpXedq
> fDDRxU5p3ME9kyYgUHwh8DaFOmyOBeP0egmiQlYvDJQnK3JfEeukJrW1NP8BvpCM
> TOQVnEjz3JHrBuozXqjrW2kGODJTM/h+eubYgHHOc1zCuxkgKBJfwvdsV4WsszNB
> BryveNLku1/Zy2fwaEtXUhYS0BP3izswb0RzBClCLoIc1CLnz4ULQ96wGACkzeKj
> mWG/4+/LxF+ek/mYAj0jFEFTZUaPI33zkzlHqhd/TxnEf3cszWOZQY3cL5kV0Zmn
> lx8BM3KxTW/qSCadWLcv9glSsiO5qWExsX0aBgqHFGDv1lZSg+FVhAc1tIG6ewc0
> G3KLIZJNHNhwBpNxlt+dNSk3Ri/v7aRYnU+oZCut2jcq/Ztiu64=
> =EYgI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

502 Proxy Error

[TED SPRADLEY]

I've worked on this for three days and at this point am not sure where to
begin debugging. 

I don't know if this is a SSL Cert issue, an Apache Reverse Proxy issue, a
Tomcat Connector issue or a Tomcat import of the SSL Cert issue.

Any feedback is much appreciated.

Thank you in advance,
Ted S.

Server version: Apache Tomcat/7.0.68
Server built:   Feb 8 2016 20:25:54 UTC
Server number:  7.0.68.0
OS Name:Linux
OS Version: 3.10.0-327.3.1.el7.x86_64
Architecture:   amd64
JVM Version:1.8.0_91-b14
JVM Vendor: Oracle Corporation

Important Points:
1. Apache was unable to be restarted without reboot.
2. After reboot requests to https://example.com/somecontext receive "502
Proxy Error"
3. I rekeyed SSL Certs and re-imported into Tomcat (command below)
4. Requests to https://example.com/somecontext still receive "502 Proxy
Error"
4. I suspect one problem may be with contents of the  element

After a recent reboot I encountered the following issue.

Issue: Requests via browser client to https://example.com/somecontext
return -
-- begin browser page
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.

Reason: Error reading from remote server
-- end browser page

Unexpected Observed Behavior: Requests via browser client to
https://www.example.com/ return the default index.html for the server.
Requests via command line client curl https://www.example.com/ return "502
Proxy Error"

This server has been in production for seven months correctly responding
to requests on ports 80 & 443 (with secure content). I updated content and
wanted to change to redirecting incoming requests from port 80 to port 443.

When I attempted to restart Apache, Apache failed to kill the running
process. I issued 'kill'. Then tried to start. Apache failed to start. I
restored the  container to the state listed below, then
tried to start Apache. Apache failed to start. I rebooted the server, then
started Apache. 

Then any request via browser behaved as above. I then rekeyed the SSL Cert
and re-imported the cert into Tomcat with:

$ openssl pkcs12 -export -in /etc/pki/tls/certs/example.com.crt -inkey
/etc/pki/
tls/private/example.key -out examplecert.p12 -name tomcat -CAfile
/etc/pki/tls/certs/ca_bundle.crt -caname root -chain

Configuration files content:

-- begin virtualhost.conf

  ServerName www.example.com
  ServerAlias example.com *.example.com
  ProxyRequests off
  ProxyPreserveHost on
  ProxyPass / http://example.com:8081/
  ProxyPassReverse / http://example.com:8081/
  ProxyPass /somecontext  http://example.com:8081/somecontext
  ProxyPassReverse  /somecontext  http://example.com:8081/somecontext



  ServerName www.exampledefaultdomain.com
  ServerAlias exampledefaultdomain.com *.exampledefaultdomain.com



  ServerName www.example.com
  ServerAlias example.com *.example.com
  ProxyRequests off
  ProxyPreserveHost on
  CustomLog "/etc/httpd/logs/examplessl.log" "%h %l %u %t \"%r\" %>s %b"
  ErrorLog "/etc/httpd/logs/examplessl_error.log"
  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /path/to/certs/example.com.crt
  SSLCertificateKeyFile /path/to/keys/example.key
  SSLCertificateChainFile /path/to/certs/ca_bundle.crt
  ProxyPass / http://example.com:8443/
  ProxyPassReverse / http://example.com:8443/
  ProxyPass /somecontext  http://example.com:8443/somecontext
  ProxyPassReverse  /somecontext  http://example.com:8443/somecontext

-- end virtualhost.conf

-- begin ssl.conf -

  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn
  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCertificateFile /path/to/certs/example.com.crt
  SSLCertificateKeyFile /path/to/keys/example.key
  SSLCACertificateFile /path/to/certs/ca_bundle.crt

-- end ssl.conf -

-- begin Tomcat server.xml Connector:

-- end Tomcat server.xml Connector:


$ openssl x509 -in /etc/pki/tls/certs/example.com.crt -noout -subject
subject= /OU=Domain Control Validated/CN=example.com

$ apachectl -S

VirtualHost configuration:
*:443  is a NameVirtualHost
 default server www.example.com (/etc/httpd/conf.d/ssl.conf:56)
 port 443 namevhost www.example.com (/etc/httpd/conf.d/ssl.conf:56)
 port 443 namevhost www.example.com
(/etc/httpd/conf.d/virtualhosts.conf:35)
 alias example.com
 wild alias *.example.com
*:80   is a NameVirtualHost
 default server www.example.com
(/etc/httpd/conf.d/virtualhosts.conf:13)
 port 80 namevhost www.example.com
(/etc/httpd/conf.d/virtualhosts.conf:13)
 alias example.com
 wild alias *.example.com




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

Re: RemoteEndpoint.Async sendText blocking

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Z, V, etc.,

On 6/29/17 1:16 PM, V User wrote:
> Hello! I have a question about the RemoteEndpoint.Async sendText
> method. The spec states: "Initiates the asynchronous transmission
> of a text message. This method returns before the message is
> transmitted." To me, this implies that the method should return
> immediately regardless of network status (i.e. it should still
> return immediately even if the socket connection has died without
> closing), but I've observed it blocking on writes to a broken
> connection.
> 
> I'm also dealing with a known issue with timeouts on Tomcat 7 with
> a BIO connector
> (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking at
> the source, the Basic/blocking sendText method calls
> sendPartialString, which uses a Future in the same way that the
> Async sendText method does, and then calls get on that Future with
> the configured timeout, so I'd imagine that if the Basic/blocking
> method has broken timeouts then the Async timeouts will be broken
> as well.
> 
> Am I mis-interpreting the spec by expecting Async sendText to
> return immediately if the socket connection is broken? Is this just
> an extension of the issue with BIO connectors?
> 
> My version information is: Server version: Apache Tomcat/7.0.64 
> Server built:   Aug 19 2015 17:18:06 UTC Server number:  7.0.64.0 
> OS Name:Linux OS Version: 3.13.0-57-generic 
> Architecture:   amd64 JVM Version:1.8.0_131-b11 JVM Vendor:
> Oracle Corporation
> 
> Thanks, Z

Are you in fact using a BIO connector? Because you can't really expect
non-blocking semantics with an underlying pro-blocking connector.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllVO1AACgkQHPApP6U8
pFiZshAApYCGkyjEoMBgCcn9p8UI9HU9Psk62dK8AW40COsc+EeRG7ZdJMB0a1Qs
ajVcN/hwoPzq5Ml1MbWZOoY0qyRPyb0of9e2ZXKi3xX5PpIAe/CJDrnrU9eyzZ9z
VTNlkTfD7lcAjfgmlNM23daiAbLs1e5teO4fjGrgARWeElK0wJfbeYZvFIQmUY+N
sYrsegoy5qYoQ9A5pi9x4ZnrJNsokTZ0FJm/HKpZ9lLzvoCOVkqONNZtd/ak+TO4
12AQzU2hRzyRmcSwRRJtbMQ6BzoOiTmKcIodlnwDtWkw1DNg6VVOWMTvF7gpXedq
fDDRxU5p3ME9kyYgUHwh8DaFOmyOBeP0egmiQlYvDJQnK3JfEeukJrW1NP8BvpCM
TOQVnEjz3JHrBuozXqjrW2kGODJTM/h+eubYgHHOc1zCuxkgKBJfwvdsV4WsszNB
BryveNLku1/Zy2fwaEtXUhYS0BP3izswb0RzBClCLoIc1CLnz4ULQ96wGACkzeKj
mWG/4+/LxF+ek/mYAj0jFEFTZUaPI33zkzlHqhd/TxnEf3cszWOZQY3cL5kV0Zmn
lx8BM3KxTW/qSCadWLcv9glSsiO5qWExsX0aBgqHFGDv1lZSg+FVhAc1tIG6ewc0
G3KLIZJNHNhwBpNxlt+dNSk3Ri/v7aRYnU+oZCut2jcq/Ztiu64=
=EYgI
-END PGP SIGNATURE-

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

RemoteEndpoint.Async sendText blocking

[V User]

Hello! I have a question about the RemoteEndpoint.Async sendText method.
The spec states: "Initiates the asynchronous transmission of a text
message. This method returns before the message is transmitted." To me,
this implies that the method should return immediately regardless of
network status (i.e. it should still return immediately even if the socket
connection has died without closing), but I've observed it blocking on
writes to a broken connection.

I'm also dealing with a known issue with timeouts on Tomcat 7 with a BIO
connector (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking
at the source, the Basic/blocking sendText method calls sendPartialString,
which uses a Future in the same way that the Async sendText method does,
and then calls get on that Future with the configured timeout, so I'd
imagine that if the Basic/blocking method has broken timeouts then the
Async timeouts will be broken as well.

Am I mis-interpreting the spec by expecting Async sendText to return
immediately if the socket connection is broken? Is this just an extension
of the issue with BIO connectors?

My version information is:
Server version: Apache Tomcat/7.0.64
Server built:   Aug 19 2015 17:18:06 UTC
Server number:  7.0.64.0
OS Name:Linux
OS Version: 3.13.0-57-generic
Architecture:   amd64
JVM Version:1.8.0_131-b11
JVM Vendor: Oracle Corporation

Thanks,
Z

Re: Tomcat managed server

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Subhro,

On 6/29/17 11:57 AM, Subhro Paul wrote:
> Can you tell me if we can create manged server in tomcat like we
> can do in Weblogic server?
> 
> I have Googled that and found information which is about setting
> up different tomcat instances but not the managed server which we
> can do in Weblogic.
For those of us unfamiliar with WebLogic... can you explain what a
"managed server in Tomcat" is?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllVLFMACgkQHPApP6U8
pFg8Vw//WcSo7+ynxMQvNsiJdiJ+HP+qPrkH5reYUvyYfj5D0f0W8RfCt5yvB1Um
jdww+T9tpYbt2nt5iWYjBx27x9DbhTuJt/OnUNfZQw7PAP2S4L0Q6Amim7yQNzau
1nbRxpfSL4rBzR2aQvwNokyd1Uqy1Wwujkf8x4ozphAhtrpeX0ctYHJupusUAXZf
ijQgDypgwWkPk2LpWkOQDF3jfsFqim/JRsw6DhRvV/u9jfPWGThmKUGF0JkilB+W
kkiIjA3eH03HS/S+wIJBQ3tJoEbTo5H8Xg786hdO3Z1fCyUV13THK+wihLM1WlcA
OLvBQlEn/Ms2tQKV1HOfMr4O4EOsxh+1yAz0Wh7oli0dOC8uurSxqI3J0oYbRP99
d8RJbbNumMXuK0OYo6Gihs/M9dAtafLV1gamACFCBl4HSMTYUBn0NulImcznnX9X
bue+lO2c+yeg2RAC5gOQnlq9VVcf+bOYRlak9rz5kdA9tp1XPQn9A3112HI0ebe3
kuIe8eZMO0hbw/lrPG+kjdnjjCrFzeU6QQodnsZh6oZ1V1rB+A9acn9UeMuXOe6F
gT9GPuxSCRciU3CScNd+9KjT5uEFXvGmP7Dmb7XFCsE4VRIDRFNhE7zRRsmrZfkX
4ProlRh9mryxJUyf1r+OLGK7kJOFccb+e4q19+7sVqfswHU+9xc=
=sxgZ
-END PGP SIGNATURE-

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

Tomcat managed server

[Subhro Paul]

Hi All,

Can you tell me if we can create manged server in tomcat like we can do in 
Weblogic server? I have Googled that and found information which is about 
setting up different tomcat instances but not the managed server which we can 
do in Weblogic.

Thanks & Regards,
Subhro Paul
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: websocket: connections not getting closed properly

[Sandeep Dhameshia]

Thanks Anurag,

Will keep an eye on this. Btw am not using auto scaling.

On Jun 29, 2017 17:59, "anurag gupta"  wrote:

> Beware of the AWS ALB, It has a nasty bug where it terminates a chunk of
> connections even if they are active. This happens after 10-12 hrs. and
> related to the autoscaling of ALB.
>
> On Thu, Jun 29, 2017 at 5:40 PM, Sandeep Dhameshia <
> sandeep.dhames...@gmail.com> wrote:
>
> > Update:
> >
> > Started using AWS Application Load Balancer, with SSL offload. This has
> > reduced CPU utilization by 5 times!
> >
> > And most importantly, wrt this mail chain, num of connections looks
> stable
> > now, with same load. Can see some Client TLS Negotiations Errors in LB's
> > monitoring console. Num of errors for some period of time are more or
> less
> > matching with num of connections increased previously.
> >
> > Sandeep
> >
> > On Fri, Jun 23, 2017 at 2:34 PM, Sandeep Dhameshia <
> > sandeep.dhames...@gmail.com> wrote:
> >
> > > One more doubt, does it log anything when max connections limit is
> > reached
> > > and it starts dropping requests? This happened few days back, and since
> > it
> > > is a production server I did not have time to see num of file
> descriptors
> > > for tomcat process and response code to client. Nothing was logged,
> > > restarted tomcat and it started accepting client requests again.
> > >
> > > Have created a cron job after this incident, which restarts the server
> > > when it is reaching the limit.
> > >
> > > regards
> > >
> > > On Wed, Jun 21, 2017 at 9:41 AM, Sandeep Dhameshia <
> > > sandeep.dhames...@gmail.com> wrote:
> > >
> > >> Thanks for your reply Mark,
> > >>
> > >> *log msg*:
> > >>
> > >> Jun 08, 2017 10:13:07 AM org.apache.tomcat.websocket.se
> > >> rver.WsRemoteEndpointImplServer doClose
> > >> INFO: Failed to close the ServletOutputStream connection cleanly
> > >> java.io.IOException: Broken pipe
> > >> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> > >> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> > >> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> > >> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> > >> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:492)
> > >> at org.apache.tomcat.util.net.SecureNioChannel.flush(SecureNioC
> > >> hannel.java:141)
> > >> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
> > >> hannel.java:385)
> > >> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
> > >> hannel.java:413)
> > >> at org.apache.coyote.http11.upgrade.NioServletOutputStream.doCl
> > >> ose(NioServletOutputStream.java:138)
> > >> at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
> > >> .close(AbstractServletOutputStream.java:129)
> > >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> > >> r.doClose(WsRemoteEndpointImplServer.java:138)
> > >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.close(W
> > >> sRemoteEndpointImplBase.java:696)
> > >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> > >> r.onWritePossible(WsRemoteEndpointImplServer.java:113)
> > >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> > >> r.doWrite(WsRemoteEndpointImplServer.java:81)
> > >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
> > >> ssagePart(WsRemoteEndpointImplBase.java:456)
> > >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> > >> ssage(WsRemoteEndpointImplBase.java:344)
> > >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> > >> ssageBlock(WsRemoteEndpointImplBase.java:276)
> > >> at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
> > >> sion.java:559)
> > >> at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:465)
> > >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.onEr
> > >> ror(WsHttpUpgradeHandler.java:162)
> > >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.acce
> > >> ss$300(WsHttpUpgradeHandler.java:48)
> > >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
> > >> adListener.onError(WsHttpUpgradeHandler.java:230)
> > >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
> > >> adListener.onDataAvailable(WsHttpUpgradeHandler.java:213)
> > >> at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
> > >> onDataAvailable(AbstractServletInputStream.java:203)
> > >> at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
> > >> spatch(AbstractProcessor.java:93)
> > >> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
> > >> .process(AbstractProtocol.java:623)
> > >> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > >> (NioEndpoint.java:1749)
> > >> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
> > >> NioEndpoint.java:1708)
> > >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> > >> Executor.java:1145)
> > >> at 

Re: websocket: connections not getting closed properly

[anurag gupta]

Beware of the AWS ALB, It has a nasty bug where it terminates a chunk of
connections even if they are active. This happens after 10-12 hrs. and
related to the autoscaling of ALB.

On Thu, Jun 29, 2017 at 5:40 PM, Sandeep Dhameshia <
sandeep.dhames...@gmail.com> wrote:

> Update:
>
> Started using AWS Application Load Balancer, with SSL offload. This has
> reduced CPU utilization by 5 times!
>
> And most importantly, wrt this mail chain, num of connections looks stable
> now, with same load. Can see some Client TLS Negotiations Errors in LB's
> monitoring console. Num of errors for some period of time are more or less
> matching with num of connections increased previously.
>
> Sandeep
>
> On Fri, Jun 23, 2017 at 2:34 PM, Sandeep Dhameshia <
> sandeep.dhames...@gmail.com> wrote:
>
> > One more doubt, does it log anything when max connections limit is
> reached
> > and it starts dropping requests? This happened few days back, and since
> it
> > is a production server I did not have time to see num of file descriptors
> > for tomcat process and response code to client. Nothing was logged,
> > restarted tomcat and it started accepting client requests again.
> >
> > Have created a cron job after this incident, which restarts the server
> > when it is reaching the limit.
> >
> > regards
> >
> > On Wed, Jun 21, 2017 at 9:41 AM, Sandeep Dhameshia <
> > sandeep.dhames...@gmail.com> wrote:
> >
> >> Thanks for your reply Mark,
> >>
> >> *log msg*:
> >>
> >> Jun 08, 2017 10:13:07 AM org.apache.tomcat.websocket.se
> >> rver.WsRemoteEndpointImplServer doClose
> >> INFO: Failed to close the ServletOutputStream connection cleanly
> >> java.io.IOException: Broken pipe
> >> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> >> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> >> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> >> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> >> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:492)
> >> at org.apache.tomcat.util.net.SecureNioChannel.flush(SecureNioC
> >> hannel.java:141)
> >> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
> >> hannel.java:385)
> >> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
> >> hannel.java:413)
> >> at org.apache.coyote.http11.upgrade.NioServletOutputStream.doCl
> >> ose(NioServletOutputStream.java:138)
> >> at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
> >> .close(AbstractServletOutputStream.java:129)
> >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> >> r.doClose(WsRemoteEndpointImplServer.java:138)
> >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.close(W
> >> sRemoteEndpointImplBase.java:696)
> >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> >> r.onWritePossible(WsRemoteEndpointImplServer.java:113)
> >> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
> >> r.doWrite(WsRemoteEndpointImplServer.java:81)
> >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
> >> ssagePart(WsRemoteEndpointImplBase.java:456)
> >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> >> ssage(WsRemoteEndpointImplBase.java:344)
> >> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
> >> ssageBlock(WsRemoteEndpointImplBase.java:276)
> >> at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
> >> sion.java:559)
> >> at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:465)
> >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.onEr
> >> ror(WsHttpUpgradeHandler.java:162)
> >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.acce
> >> ss$300(WsHttpUpgradeHandler.java:48)
> >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
> >> adListener.onError(WsHttpUpgradeHandler.java:230)
> >> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
> >> adListener.onDataAvailable(WsHttpUpgradeHandler.java:213)
> >> at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
> >> onDataAvailable(AbstractServletInputStream.java:203)
> >> at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
> >> spatch(AbstractProcessor.java:93)
> >> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
> >> .process(AbstractProtocol.java:623)
> >> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> >> (NioEndpoint.java:1749)
> >> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
> >> NioEndpoint.java:1708)
> >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> >> Executor.java:1145)
> >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> >> lExecutor.java:615)
> >> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
> >> run(TaskThread.java:61)
> >> at java.lang.Thread.run(Thread.java:745)
> >>
> >> *Connector*:
> >>
> >>  >>protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>port="8443" maxThreads="200"
> >>

Re: websocket: connections not getting closed properly

[Sandeep Dhameshia]

Update:

Started using AWS Application Load Balancer, with SSL offload. This has
reduced CPU utilization by 5 times!

And most importantly, wrt this mail chain, num of connections looks stable
now, with same load. Can see some Client TLS Negotiations Errors in LB's
monitoring console. Num of errors for some period of time are more or less
matching with num of connections increased previously.

Sandeep

On Fri, Jun 23, 2017 at 2:34 PM, Sandeep Dhameshia <
sandeep.dhames...@gmail.com> wrote:

> One more doubt, does it log anything when max connections limit is reached
> and it starts dropping requests? This happened few days back, and since it
> is a production server I did not have time to see num of file descriptors
> for tomcat process and response code to client. Nothing was logged,
> restarted tomcat and it started accepting client requests again.
>
> Have created a cron job after this incident, which restarts the server
> when it is reaching the limit.
>
> regards
>
> On Wed, Jun 21, 2017 at 9:41 AM, Sandeep Dhameshia <
> sandeep.dhames...@gmail.com> wrote:
>
>> Thanks for your reply Mark,
>>
>> *log msg*:
>>
>> Jun 08, 2017 10:13:07 AM org.apache.tomcat.websocket.se
>> rver.WsRemoteEndpointImplServer doClose
>> INFO: Failed to close the ServletOutputStream connection cleanly
>> java.io.IOException: Broken pipe
>> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
>> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
>> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
>> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
>> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:492)
>> at org.apache.tomcat.util.net.SecureNioChannel.flush(SecureNioC
>> hannel.java:141)
>> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
>> hannel.java:385)
>> at org.apache.tomcat.util.net.SecureNioChannel.close(SecureNioC
>> hannel.java:413)
>> at org.apache.coyote.http11.upgrade.NioServletOutputStream.doCl
>> ose(NioServletOutputStream.java:138)
>> at org.apache.coyote.http11.upgrade.AbstractServletOutputStream
>> .close(AbstractServletOutputStream.java:129)
>> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
>> r.doClose(WsRemoteEndpointImplServer.java:138)
>> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.close(W
>> sRemoteEndpointImplBase.java:696)
>> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
>> r.onWritePossible(WsRemoteEndpointImplServer.java:113)
>> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServe
>> r.doWrite(WsRemoteEndpointImplServer.java:81)
>> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMe
>> ssagePart(WsRemoteEndpointImplBase.java:456)
>> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
>> ssage(WsRemoteEndpointImplBase.java:344)
>> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMe
>> ssageBlock(WsRemoteEndpointImplBase.java:276)
>> at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSes
>> sion.java:559)
>> at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:465)
>> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.onEr
>> ror(WsHttpUpgradeHandler.java:162)
>> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.acce
>> ss$300(WsHttpUpgradeHandler.java:48)
>> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
>> adListener.onError(WsHttpUpgradeHandler.java:230)
>> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsRe
>> adListener.onDataAvailable(WsHttpUpgradeHandler.java:213)
>> at org.apache.coyote.http11.upgrade.AbstractServletInputStream.
>> onDataAvailable(AbstractServletInputStream.java:203)
>> at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDi
>> spatch(AbstractProcessor.java:93)
>> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
>> .process(AbstractProtocol.java:623)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>> (NioEndpoint.java:1749)
>> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
>> NioEndpoint.java:1708)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1145)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:615)
>> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
>> run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> *Connector*:
>>
>> >protocol="org.apache.coyote.http11.Http11NioProtocol"
>>port="8443" maxThreads="200"
>>scheme="https" secure="true" SSLEnabled="true"
>>keystoreFile="${catalina.base}/conf/.keystore"
>> keystorePass="dummy"
>>clientAuth="false" sslProtocol="TLS"
>>   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA
>> _WITH_AES_128_CBC_SHA,
>>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES
>> _256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
>>   TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_
>>