When we run our app for 2-3 hours we experience this leak related to our web sockets connections: One instance of "org.apache.coyote.AbstractProtocol$ConnectionHandler" loaded by "java.net.URLClassLoader @ 0x720029098" occupies 2,153,196,128 (88.10%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class loader>". Keywords org.apache.coyote.AbstractProtocol$ConnectionHandler java.util.concurrent.ConcurrentHashMap$Node[] java.net.URLClassLoader @ 0x720029098 Please help
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.