Getting confusing websocket error message on Tomcat 7

[Jason Ricles]

I am trying to send a file over a websocket in binary and keep getting
this error

"code [1009], reason [No async message support and buffer too small.
Buffer size: [800,000], Message size: [131,170]]"

I am confused since it is saying the buffer size is too small but the
size is 800,000 and the message size is 131,170. What could be causing
this issue?

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

Re: Apache Tomcat8 blocked once reached max thread(s) count

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David,

On 5/2/16 7:29 AM, David kerber wrote:
> On 5/2/2016 3:33 AM, Kapilan A wrote:
>> Hi Folks
>> 
>> I am facing one issue with Apache Tomcat 8.
>> 
>> 
>> 
>> In 32 GB machine, four instances of tomcat is running and every
>> tomcat has memory as 512-1024.
>> 
>> 
>> 
>> In the SQl server, a particular table called "MetaData".
>> 
>> 
>> 
>> Third party engine will post a http request through tomcat. it
>> accepts max thread as 150. Savings will happen in MetaData table
>> which is around 8 million records.
>> 
>> 
>> 
>> After 12 hours continuously posting, then one of the tomcat is
>> freeze. Its not accepting any more connections from third party
> 
> Without knowing anything about your app, I'd guess you have a
> statement or connection leak, causing the db to not accept any more
> connections.

+1

Enable "abandoned connection logging" and see what comes out.

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

iEYEARECAAYFAlcqPrEACgkQ9CaO5/Lv0PBJNwCdGnwRkp+4jAMrnv/3ItqFEdKg
Bq4An0IBinbq1gTUZfCXpu1GmrwcWmj1
=gBKf
-END PGP SIGNATURE-

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

Re: heap space problem

[Yaragalla Muralidhar]

Thank you Chris. Your mail is so helpful


*Thanks and Regards,*
Muralidhar Yaragalla.
*http://yaragalla.blogspot.in/ *

Re: heap space problem

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yaragalla,

On 5/4/16 1:13 PM, Yaragalla Muralidhar wrote:
> Hi we have purchased a java private hosting with some service
> provider and we have hosted some simple spring app with few
> database operations. the heap space we got is 64mb.

Spring is a pig. Often, the *permgen* needs to be more than 64MiB. A
64MiB heap is pretty much never going to meet your needs.

> some times it used to get stopped so when we ask the service
> provider he said we have to increase the heap space and we have 
> increased it to 128 mb and now the service provider says my app is
> taking nearly 350 mb heap space.

If you have a constrained heap, the heap itself won't exceed that. But
Java processes use more than just the heap space, so your provider is
probably talking about the full process memory, not the Java heap space.

> I am not sure what is going on. does a simple spring app takes more
> than 100mb. i have checked my app on tomcat 7 (on my laptop) and it
> does not take much than 80mb. I have checked with jvisualvm that
> comes with jdk.
> 
> can u provide some help on this.

My (vicarious) experience is that Spring-based web apps require a
great deal of heap space because *tons* of stuff gets loaded. Tomcat
with no applications requires about 12MiB of heap space the last time
I checked.

You need to talk to your hosting provider about what is and is not
reasonable for a server-side web application -- especially one that is
Java-based. Many el-cheapo-webapps are written in PHP which doesn't
even stay resident between requests, so memory usage is fairly low
unless you catch a long-running script. Java is a different beast and
if the service provider doesn't know that, they shouldn't be offering
it as a service.

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

iEYEARECAAYFAlcqO4MACgkQ9CaO5/Lv0PAycgCeIcs/1P7EiQ720RB0U6j1p46s
kycAn3SqnR2w53KrKga+YwO9I2rMCr73
=g+jJ
-END PGP SIGNATURE-

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

heap space problem

[Yaragalla Muralidhar]

Hi we have purchased a java private hosting with some service provider and
we have hosted some simple spring app with few database operations. the
heap space we got is 64mb. some times it used to get stoped so when we ask
the service provider he said we have to increase the heap space and we have
increased it to 128 mb and now the service provider says my app is taking
nearly 350 mb heap space. I am not sure what is going. does a simple spring
app takes more than 100mb. i have checked my app on tomcat 7 (on my
laptop)and it does not take much than 80mb. I have checked with jvisualvm
that comes with jdk.

can u provide some help on this.

*Thanks and Regards,*
Muralidhar Yaragalla.

*http://yaragalla.blogspot.in/ *

Re: Tomcat accept count tuning

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rallavagu,

On 5/2/16 3:20 PM, Rallavagu wrote:
> Tomcat 7.0.47 running on Linux

Upgrade, dude. Disclosed vulnerabilities are available for your
version of Tomcat.

> I have started investigating after noticing following messages
> from "dmesg" output on a production server.
> 
> "possible SYN flooding on port 28080. Sending cookies."
> 
> Started looking into this as the connections to this server are
> timing out (Connect Timeout errors). Upon further investigation, it
> appears to me that Linux's kernel maintain two different queues one
> for SYN and one for ESTABLISHED/accept connections.

UNIX sockets don't have an "accept" backlog at all for ESTABLISHED
connections. "accept" is a queue where connections are put when the
kernel has accepted the connection, but the application has not. Once
the application accepts the connection, it's no longer in the "accept"
queue.

> Both are determined by following parameters.
> 
> $ cat /proc/sys/net/ipv4/tcp_max_syn_backlog 2048
> 
> $ cat /proc/sys/net/core/somaxconn 128

There are two separate backlogs, but they don't correspond to what you
said above.

> Also, it appears that the second parameter (accept count) is
> determined by the application.

Correct, somewhat. See below.

> For tomcat it defaults to 100. As per this document -
> http://blog.dubbelboer.com/2012/04/09/syn-cookies.html above two 
> parameters could be tuned to increase the accepted connections. 
> Wondering if Tomcat's "acceptCount" 
> (http://tomcat.apache.org/tomcat-7.0-doc/config/http.html)
> parameter is related to "somaxconn" for tuning.

Oddly enough, the kernel has a backlog that the application CANNOT
control. If the application requests a backlog, it will be separate
from the kernel's backlog.

There is nothing you can do at the Tomcat/Java/application level to
avoid a SYN attack. If you are getting a SYN attack, then you need to
increase your SYN backlog, or tweak some of the TCP handshake timeouts
to eliminate connections that aren't actually doing anything.

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

iEYEARECAAYFAlcqKfQACgkQ9CaO5/Lv0PDhjwCeJgeQaP9+SyQAQlJyUtOsIgSa
sPAAoJ69oV3qiPJxk8k37ZeCtLVyyEbE
=O3GA
-END PGP SIGNATURE-

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

Re: Tomcat connector settings

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael,

On 5/2/16 10:20 AM, Michael Fox wrote:
> I ultimately want to have a Tomcat application protected  by our 
> university's system for authentication, which is SiteMinder.  They 
> have told me that they can't protect Tomcat directly, but if user 
> communications can be passed through a web server then they can 
> protect the server with SiteMinder.

No problem.

> I have a working Tomcat application if I uncomment the non-SSL 
> HTTP/1.1 protocol in the Tomcat, but I believe I need all 
> communication to pass through the Apache web server.  Let me know
> if you need more information and, if so, what that would be.

You can use HTTP, HTTPS, or AJP as the communication mechanism between
the web server and Tomcat.

AJP works great with Apache httpd, but may be more complicated to get
set up with other web servers. HTTP is, by definition, always
supported. You want them to set up the web server as a
"reverse-proxy", and just give them the URL of your base application.
The configuration in httpd for using HTTP as the protocol is fairly
simple:

ProxyPass /myapp http://internal.ip:8080/myapp
ProxyPassReverse /myapp http://internal.ip:8080/myapp

You'll want to enable the standard HTTP connector (it was enabled by
default) and if you aren't using AJP (like you are NOT in this
example), then you'll want to enable the RemoteIPValve:
https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Val
ve

That "valve" takes information from the HTTP headers coming from the
web server and makes sure that things like the base URL match what the
client is seeing from the outside world (e.g. they won't see URLs for
http://internal.ip:8080/etc.).

On the web server, you can use whatever protocol you want for your
clients. HTTPS is a good choice. Using HTTPS on the web server has no
impact on whether or not you want to use HTTP or HTTPS internally on
your private network. If you want to use HTTPS internally (also not a
bad idea, especially if you don't 100% trust everyone who has access
to your network), change the httpd configuration to this:

ProxyPass /myapp http://internal.ip:8443/myapp
ProxyPassReverse /myapp http://internal.ip:8443/myapp

You will, of course, have to configure a secure  on port
8443 for that purpose, including a TLS certificate, etc. If you always
expect to use a secure connection, then disable the non-secure
: anyone coming to your web site using cleartext HTTP can
be redirected by the web server to HTTPS so Tomcat itself only has to
be providing an HTTPS connection.

Hope that helps,
- -chris

> -Original Message- From: Christopher Schultz 
> [mailto:ch...@christopherschultz.net] Sent: Friday, April 29, 2016 
> 9:14 PM To: Tomcat Users List  Subject:
> Re: Tomcat connector settings
> 
> Michael,
> 
> On 4/29/16 4:25 PM, Michael Fox wrote:
>> I have an Apache web server(2.4.6) which is accessible at http or
>>  https at DNS_hostname, and a Tomcat server (9.0.0.M1)with an 
>> application available at DNS_hostname:8080/app_name.
> 
>> I then disabled the non-SSL HTTP/1.1 connector on port 8080 and 
>> enabled HTTP/2 in the Tomcat server.xml, using the certificate
>> key file and certificate where generated using the openssl
>> (1.0.2g) commands and used on the Apache web server.
> 
>> The Apache ssl.conf file is set to listen on port 8443 for
>> https, and the only virtual host is set for IP_address:8443 and
>> servername set to DNS_hostname
> 
>> In the file /etc/httpd/conf/workers.properties,
>> worker.worker1.host is set to DNS_hostname and
>> worker.worker1.port is set to 8443.
> 
>> Netstat -tamp shows httpd listening on port 8443 and java
>> listening on port 8009.
> 
>> Are these settings proper and correct?
> 
> It doesn't look like it.
> 
>> What should the URL look like in order to access the Tomcat 
>> application via Apache?
> 
> That depends upon what you are actually trying to do.
> 
>> Any help and/or guidance would most appreciated.
> 
> You have an HTTPS server listening on port 443 (httpd). You have 
> mod_jk (workers.properties) configured to connect to host:8443
> (which is the same host listening for HTTPS requests on port 8443)
> using AJP13 (not HTTP). So, if a client makes a call to host:8443,
> mod_jk will proxy the request through to host:8443. If the protocol
> were correct (it isn't), you'd have an infinite loop of request s.
> 
> Can you explain what you are actually trying to do and maybe we
> can help ?
> 
> -chris
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - 

Re: Locky Attack

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Johan,

On 5/2/16 9:50 AM, Johan Compagner wrote:
> How did they get in? what security hole was used there?

Most likely the usual: a raw meat vulnerability.

Someone opened a document they shouldn't have trusted and enabled
macros and let it do whatever dastardly thing it wanted to do.

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

iEYEARECAAYFAlcqJVoACgkQ9CaO5/Lv0PBXzwCeKpAluJ5FxR5PDLzoFsN7n+3a
SYsAn3Z2fUiMW2n2Sic6y01B3DAlFcZQ
=IC7C
-END PGP SIGNATURE-

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

Non recycled request

[Thomas Boniface]

Hi,

I can observer RecycleRequiredException (example below) in the catalina.out
of my application. This application relies on async servlets with some
async libraries, this exception can lead to strange behavior I guess like
mixing user cookies.

Is there some specific logs I could activate to isolate the use case
leading to this error ? Or some known deprecated behaviour that would lead
to this state ?

May 02, 2016 6:32:10 AM org.apache.catalina.connector.CoyoteAdapter
checkRecycled
INFO: Encountered a non-recycled request and recycled it forcedly.
org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
at
org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:592)
at
org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1814)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.release(Http11NioProtocol.java:218)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:708)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1760)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1719)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

Thanks,
Thomas