There is nothing in this report that indicates a bug in Apache Tomcat and no information that might enable a developer to reproduce the behaviour you are seeing.

Bugzilla is not a support forum. Please use the Tomcat users mailing list to debug this issue. If that discussion concludes that there is a Tomcat bug, please re-open this issue and provide the necessary steps to reproduce the issue on a clean install of the latest release of any currently supported branch.

http://tomcat.apache.org/lists.html#tomcat-users

Mark

Looks like it did not save my environment - Windows Server 2012

Also these bugs might be related to this one:

*    [57546](https://bz.apache.org/bugzilla/show_bug.cgi?id=57546)
*    [57750](https://bz.apache.org/bugzilla/show_bug.cgi?id=57750)

The 57546 bug looks very similar to what we are experiencing. We tested on Linux and so far we do not see the same behavior. Also this is our web socket code:

package ad.ecs.async.websocket;

import java.io.IOException;
import java.util.Arrays;

import javax.websocket.CloseReason;
import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

import ad.common.Global;
import ad.ecs.async.AsyncEngine;
import ad.ecs.async.AsyncResponse;
import ad.ecs.async.AsyncType;
import ad.ecs.db.DatabaseEngine;
import ad.ecs.db.paradox.User;
import ad.ecs.security.engine.SecurityEngine;

/**
 * @author Serge Perepel
 * @since Aug 23, 2017 12:23:32 PM
 */
@ServerEndpoint(value = "/asyncMsg", encoders = AsyncResponseEncoder.class)
public class ECSAsync {
    
    @OnOpen
    public void open(Session session) throws IOException{
        session.getBasicRemote().sendText("Connection Established");
    }

    @OnMessage
    public String login(String sessionID, Session session) {
    	AsyncEngine.INSTANCE.wsConnect(session, sessionID);
    	org.hibernate.Session dbSession = DatabaseEngine.getSessionFactory().openSession();
    	try {
    		int userID = SecurityEngine.INSTANCE.getUserIDBasedOnSessionID(sessionID);
    		User user = (User) dbSession.get(User.class, userID);
    		if (user != null) {
    			if (user.getNextLogin() == 1) {
    				AsyncResponse response = new AsyncResponse();
    				response.setType(AsyncType.None);
    				response.setData(Arrays.asList("PASSWORD"));
    				response.setObjData("PASSWORD");
    				AsyncEngine.INSTANCE.addTransientResult(sessionID, response);
    			}
    		}
    	} finally {
    		dbSession.close();
    	}
    	return "ok"; 
    }
    
    @OnClose 
    public void close(Session session, CloseReason reason) {
        AsyncEngine.INSTANCE.wsDisconnect(session);
    }
    
    @OnError
    public void error(Session session, Throwable error) {
        Global.INSTANCE.getLogHelper().exception(error);
        //session.close(new CloseReason(closeCode, reasonPhrase));
    }
}

Front end opens connection and sends invalid sessionID which causes
the line `AsyncEngine.INSTANCE.wsConnect(session, sessionID);` to throw exception and after that disconnect happens on the front end. At this point front end opens new connection and process goes into the loop. I'm assuming that the connection handler suppose to get freed after a disconnect happen. But it seems to accumulate. You can try this code and just replace code in the login method to always throw the exception. On the front end onDisconnect try to open new connection and send a random message to the web socket. Hopefully this will reproduce the issue for you.

We added the code to reproduce the leak:

https://www.mail-archive.com/users@tomcat.apache.org/msg128214.html

Thanks for the test case. It makes investigation so much easier. The leak stands out very clearly in a profiler.

I've tracked down a bug in the exception handling case and I have a patch for that. I still need to look at the normal close variant.

Fixed in:
- trunk for 9.0.5 onwards
- 8.5.x for 8.5.28 onwards

This appears to have been a regression in the connector refactoring in 8.5.x. Testing with 8.0.x shows it handles it correctly. Also, I could only trigger an issue when using an exception. Clean closes were handled correctly.

Thank you very much

Mark- Our technicians are wondering if there a patch fix that can be applied to existing Windows versions of Tomcat

Short answer: the Tomcat team provides replacement versions, not patches. You will need to upgrade to 8.5.28 when it becomes available.

The Tomcat 8.5 RM announced the intention of rolling a release and calling for a vote in the next few days. You are welcome to join the tomcat-dev mailing list and vote (non-binding) on the release. If all goes well, I'd expect a release to be ready for you by next Monday.