Connectiong to mongoDB with a keep-alive TCP connection?

[Hunor Kovács]

Do you know how can i set my connection to mongodb to be on a TCP session that is kept open for longer? Inside the mgo library or outside just in TCP settings, doesn't matter.

 

Thanks,

Huni

[Gustavo Niemeyer]

Hi Hunor,

The underlying implementation of mgo sessions will pool connections and will keep them alive for as long as the server accepts an unused connection alive, which is around 10 minutes. You don't need to do any extra setup for that.. just using sessions properly (please see the documentation for the Dial function and the Copy and Close methods) will give you what you need for reusing sockets properly. 

--
You received this message because you are subscribed to the Google Groups "mgo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mgo-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

gustavo @ http://niemeyer.net

[Hunor Kovács]

Tjanks, Gustavo

[bernadet...@ft.com]

Hi Gustavo,

I was searching for the default setting for the TCP keep-alive property, as you mentioned, but I didn't get too far...

What I found:

1) In net\dial.go the function Dial takes care of setting the keepalive property, as long as the Dialer has it's KeepAlive set, and the value is greater then 0. 

2) The only default setting I could find for the Dialer keepalive, is in http\transport.go, when the DefaultTransport RoundTripper is defined. Here, the KeepAlive has 30 * time.Second set as a default.

In mongolib I could not find any other related default. The timeout variable can be set, but as far as I saw, this has no effect on the keepalive value.

What am I missing here? Do you have any idea?

Thank you,

Berni.

[bernadet...@ft.com]

Here is how I finally did it.

First of all, Mongo does not uses http protocol, so the DefaultTransport settings are not considered here. In case of http, this article really helped me understand how tcp keepalive settings work with go: http://felixge.de/2014/08/26/tcp-keepalive-with-golang.html.

For mgo, I called mgo.DialWithInfo(&info) instead of DialWithTimeout, and as an argument I passed my implementation for a DialServer method (beside some other parameters).

In this method implementation, I called net.DialTCP, and for the obtained connection I could easily enable the keepalive prop, and set the keepaliveperiod value.

This seems to work as expected. :)

[Gustavo Niemeyer]

Hi Bernadette,

I understood the original question as being more about proper reuse of connections than about real issues on TCP keep alives.

Can you provide some insight about your use case regarding the use of TCP keep alives?  How was the problem surfacing?

---

This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL.  Registered in England and Wales with company number 53723.

--
You received this message because you are subscribed to the Google Groups "mgo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mgo-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Garton]

I understood the original question as being more about proper reuse of connections than about real issues on TCP keep alives.

Can you provide some insight about your use case regarding the use of TCP keep alives?  How was the problem surfacing?

I think I can answer on behalf of Bernadette (I'm involved in the work she is doing)

We use tcp keepalives to work around an issue of idle connections being dropped by one of our corporate firewalls.

I wonder whether having this on by default makes sense for mongodb?  The golang http implementation appears to use 30s tcp keepalive by default.

(Bernadette - please correct anything I got wrong or if I missed anything)

--
Martin.

[Gustavo Niemeyer]

It sounds like a good idea to enable it given our use of socket pools. Unless we hear something soon, I'll enable them for the next stable release.

Please let me know if Bernadette reaches out to you with any further insights.

--
You received this message because you are subscribed to the Google Groups "mgo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mgo-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bernadet...@ft.com]

Hi Gustavo,

Martin has described the situation correctly. Thanks for your advice as well, also it sounds good having them enabled in the next release.

Thanks,

Bernadette.

[Rob S]

Did this change make it into a release?

[Gustavo Niemeyer]

Hi Rob,

Not yet, but I'm happy to add this to the release I'm cooking.