Vaadin Atmoshpere threads leak

While I was testing my app I found that lot of threads stay in my app forever. They called Atmosphere-Shared-AsyncOp. How can I configure max and min thread count value? I saw that vaadin-atmosphere distributive has atmosphere.xml that has some properties inside it. Can I create smth similar in my web-inf folder? Because I think that problem is here https://github.com/Atmosphere/atmosphere/wiki/Configuring-Atmosphere-for-Performance in those properties.

P.S. I counted 200 atmosphere thread. I’ve tested my app from 3 browsers with 3 users.
15211.png

The same problem. Please explain how to resolve it.

Thanks!

Ok I found the way. I overrided VaadinServlet and use reflection in init method for ServletConfigs I get _initParams from it and set my custom value, but this is really not the best way how to do that. Also can someone explain me what lifecycle policy should I use for my app and it will be interesting to know what is the difference between org.atmosphere.cpr.broadcaster.maxProcessingThreads and
org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads.

Any update? Please explain, if there is any other way to fix the problem except using reflection.

You can use annotations of the servlet-class like this:

    @WebServlet(value = "/*", asyncSupported = true, initParams = {
            @WebInitParam( name = "heartbeatInterval", value = "120"),
[b]
            @WebInitParam( name = "org.atmosphere.cpr.Broadcaster.supportOutOfOrderBroadcast", value = "true"),
            @WebInitParam( name = "org.atmosphere.cpr.broadcaster.maxProcessingThreads", value = "25"),
            @WebInitParam( name = "org.atmosphere.cpr.broadcaster.maxAsyncWriteThreads", value = "25"),
[/b]
            })
    @VaadinServletConfiguration(
            productionMode = false, ui = MyUiClass.class,
            widgetset = "my.widgetset.MyWidgetset")
    public static class Servlet
        extends VaadinServlet
    {
    }

Yeah, or in web.xml if you use Servlet 2; they’re just regular servlet init params. Although nowadays it’s apparently not recommended to manually set the threadpool size; 200 threads is actually the default maximum used and not a sign of leakage. Only if you see more than 200 threads it might be an indication of a problem. 200 threads should be perfectly okay in a modern JVM, unless you have several other thread-heavy applications running on the same server. It might of course be overkill if the number of concurrent users is typically much less than that.

Thomas, Johannes, thanks for reply!