0

I have a Scala-based Play app that uses ReactiveMongo. When in development mode and a hot-reload occurs, ReactiveMongo leaks connections. For example, here is a snippet of Mongo's log files; I added a line break in the logs to indicate each time a hot-reload occurred (i.e. I made a trivial change the app and reloaded a page in the browser)

2015-09-26T09:43:43.353-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58612 #1 (1 connection now open)

2015-09-26T09:43:43.725-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58613 #2 (2 connections now open)

2015-09-26T09:43:43.725-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58614 #3 (3 connections now open)

2015-09-26T09:43:43.725-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58615 #4 (4 connections now open)

2015-09-26T09:43:43.725-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58616 #5 (5 connections now open)

2015-09-26T09:43:43.726-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58617 #6 (6 connections now open)

2015-09-26T09:43:43.726-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58618 #7 (7 connections now open)

2015-09-26T09:43:43.726-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58619 #8 (8 connections now open)

2015-09-26T09:43:43.726-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58620 #9 (9 connections now open)

2015-09-26T09:43:43.726-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58621 #10 (10 connections now open)

2015-09-26T09:43:43.810-0700 I INDEX    [conn1] build index on: sma.destination properties: { v: 1, unique: true, key: { id: 1 }, name: "idx_destination_id", ns: "sma.destination" }

2015-09-26T09:43:43.810-0700 I INDEX    [conn1]      building index using bulk method



2015-09-26T09:43:57.164-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58640 #11 (11 connections now open)

2015-09-26T09:43:57.169-0700 I NETWORK  [conn11] end connection 127.0.0.1:58640 (10 connections now open)

2015-09-26T09:43:57.431-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58641 #12 (11 connections now open)

2015-09-26T09:43:57.435-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58642 #13 (12 connections now open)

2015-09-26T09:43:57.436-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58643 #14 (13 connections now open)

2015-09-26T09:43:57.436-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58644 #15 (14 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58645 #16 (15 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58646 #17 (16 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58647 #18 (17 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58648 #19 (18 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58649 #20 (19 connections now open)

2015-09-26T09:43:57.437-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58650 #21 (20 connections now open)

2015-09-26T09:43:57.487-0700 I INDEX    [conn14] build index on: sma.destination properties: { v: 1, unique: true, key: { id: 1 }, name: "idx_destination_id", ns: "sma.destination" }

2015-09-26T09:43:57.487-0700 I INDEX    [conn14]     building index using bulk method



2015-09-26T09:44:16.559-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58677 #22 (21 connections now open)

2015-09-26T09:44:16.560-0700 I NETWORK  [conn22] end connection 127.0.0.1:58677 (20 connections now open)

2015-09-26T09:44:16.766-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58678 #23 (21 connections now open)

2015-09-26T09:44:16.770-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58679 #24 (22 connections now open)

2015-09-26T09:44:16.771-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58680 #25 (23 connections now open)

2015-09-26T09:44:16.771-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58681 #26 (24 connections now open)

2015-09-26T09:44:16.771-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58682 #27 (25 connections now open)

2015-09-26T09:44:16.772-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58683 #28 (26 connections now open)

2015-09-26T09:44:16.772-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58684 #29 (27 connections now open)

2015-09-26T09:44:16.772-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58685 #30 (28 connections now open)

2015-09-26T09:44:16.772-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58686 #31 (29 connections now open)

2015-09-26T09:44:16.772-0700 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:58687 #32 (30 connections now open)

2015-09-26T09:44:16.791-0700 I INDEX    [conn24] build index on: sma.destination properties: { v: 1, unique: true, key: { id: 1 }, name: "idx_destination_id", ns: "sma.destination" }

2015-09-26T09:44:16.792-0700 I INDEX    [conn24]     building index using bulk method

You can see that ReactiveMongo creates a pool of 10 connections each time a hot-reload occurs; the previous 10 connections don't get cleaned up. Eventually it gets to the max number of connections (currently ~ 200), and then mongo becomes inaccessible until I restart.

Presumably this wouldn't happen in prod, but I'm a little unnerved by it happening in dev in the first place. Is there any way I can close those connections when the app hot-reloads?

Dave Taubler
  • 1,081
  • 3
  • 12
  • 25

1 Answers1

0

Had the same problem following slightly outdated tutorials (using Play 2.6)

From the docs: http://reactivemongo.org/releases/0.12/documentation/tutorial/play.html

/*
 * Get a JSONCollection (a Collection implementation that is designed to work
 * with JsObject, Reads and Writes.)
 * Note that the `collection` is not a `val`, but a `def`. We do _not_ store
 * the collection reference to avoid potential problems in development with
 * Play hot-reloading.
 */
def collection: Future[JSONCollection] = database.map(
    _.collection[JSONCollection]("persons"))

In my case, replacing: val collection: JSonCollection to the format above solved my problem.

Now when reloading, it closes and reopens all the connections:

2017-08-15T15:32:50.991-0300 I -        [conn2] end connection 127.0.0.1:58489 (10 connections now open)
2017-08-15T15:32:50.992-0300 I -        [conn9] end connection 127.0.0.1:58496 (9 connections now open)
2017-08-15T15:32:50.992-0300 I -        [conn4] end connection 127.0.0.1:58491 (8 connections now open)
2017-08-15T15:32:50.993-0300 I -        [conn5] end connection 127.0.0.1:58492 (7 connections now open)
2017-08-15T15:32:50.994-0300 I -        [conn6] end connection 127.0.0.1:58493 (6 connections now open)
and so on...
user7552
  • 315
  • 1
  • 3
  • 19