[JAVA-831] Memory leak Created: 20/May/13  Updated: 19/Oct/16  Resolved: 23/May/13

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: lucie votypkova Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If authentication fails monglo cleaner thread will stuck in waiting state forever. So if you try continuously to connect to the database it causes the memory leak. I tried to look at javadoc and there is no information that it is necessary to call close() if authentication fails. And tutorial for beginner is withou calling method close() if authentication fails http://docs.mongodb.org/ecosystem/tutorial/getting-started-with-java-driver/#getting-started-with-java-driver

Here is my stackt trace
com.mongodb.MongoException$Network: IOException authenticating the connection
at com.mongodb.DBPort$NativeAuthenticator.authenticate(DBPort.java:552)
at com.mongodb.DBPort.authenticate(DBPort.java:322)
at com.mongodb.DBTCPConnector.authenticate(DBTCPConnector.java:621)
at com.mongodb.DBApiLayer.doAuthenticate(DBApiLayer.java:180)
at com.mongodb.DB.authenticateCommandHelper(DB.java:630)
at com.mongodb.DB.authenticate(DB.java:588)

I think that it should be fixed in connector in method authenticate so I send pull request for it.

If it is fixed in wrong place or in wrong way, please correct it. If it should not be fixed please update mongo java driver tutorial and javadoc to prevent that another beginner create memory leak in his application.

Thanks a lot



 Comments   
Comment by Vojtech Juranek [ 28/May/13 ]

If I don't close Sockets, AFAIK I don't run into OOM. If, for any reason, close() is not call (somethign unexpected happens, you undeploy the app without calling it - see e.g. JAVA-817), Mongo objects will be kept in memory forever. I'm not saying it's unreasonable design, but rather unexpected as I would expect that these objects are removed by GC later on. If not, in such case I would expect Mongo to be a singleton so that there is only one instance.

Comment by Jeffrey Yemin [ 28/May/13 ]

You just need to call close() the Mongo instance. I don't think this is an unreasonable design choice. It's no different in principle than having to call close() on a Socket, for instance.

Comment by Vojtech Juranek [ 27/May/13 ]

Hi,
authenticate is not the only case, basically it can happen elsewhere and CursorCleanerThread will be kept in JVM (together with Mongo object), until JVM finishes. IMHO this is not a comfortable design. Do you consider e.g. moving CursorCleanerThread into separate class and reference Mongo object by a weak reference (with checking, if referenced mongo instance is not null in CursorCleanerThread#run - if it's null, it was GCed and thread can finish)?
Thanks

Comment by Trisha Gee [ 23/May/13 ]

Thanks for the pull request, but this is not really the correct behaviour - "authenticate" in DBTCPConnector should not be responsible for closing anything, this would be unexpected to the user.

It's really down to the calling code to ensure that the authenticate method passed, and deal with failures in a way that is appropriate to the application or business, your application should know how to handle authentication failures.

Comment by lucie votypkova [ 20/May/13 ]

here is my pull request https://github.com/mongodb/mongo-java-driver/pull/117

Generated at Thu Feb 08 08:53:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.