[ANN] mgo r2013.01.20

310 views
Skip to first unread message

Gustavo Niemeyer

unread,
Jan 20, 2013, 10:16:04 PM1/20/13
to golan...@googlegroups.com, mongod...@googlegroups.com, mgo-...@googlegroups.com
Hello all,

The release r2013.01.20 of the mgo MongoDB driver for Go is out
with fixes and minor improvements.

Details about the driver may be found in its web page:

http://labix.org/mgo

The following changes were made in this release:

- Ensure open cursor is killed before finishing an iterator with
limit. Issue reported by Andrew Bonventre.

- Fixed bson's omitempty handling on float values, as reported
by Otto Bretz.

- New bson.IsObjectIdHex function to verify whether a given
string is a valid hex representation of an object id. This is useful
in conjunction with the ObjectIdHex function, which panics on
invalid ids. More details in the documentation:

http://labix.org/v2/mgo/bson#IsObjectIdHex

- The DialWithInfo function was fixed so it dials to the standard
MongoDB port if the address doesn't inform one. Thanks to
Mark Severson for reporting the issue.

More details about the function at:

http://labix.org/v2/mgo#DialWithInfoo

- In preparation for 2.4, which is coming with multiple new index
types, the format of 2D indexes as accepted by
Collection.EnsureIndex and returned by Collection.Indexes was
changed from "@field" to "$2d:field", and the index type is not
validated before being sent to the server. Parsing of the old
style is still maintained for compatibility.

More details about index creation is available in the documentation:

http://labix.org/v2/mgo#Collection.EnsureIndex

- Added a note to the GridFile.Write method explaining that errors
may be delayed until a future Write or Close due to chunking,
as suggested by Ian Ragsdale.

- Fixed typo in documentation sample. Contributed by Livio Soares.


gustavo @ http://niemeyer.net

Nimi Wariboko Jr

unread,
Jan 28, 2013, 6:38:36 PM1/28/13
to mgo-...@googlegroups.com, golan...@googlegroups.com, mongod...@googlegroups.com
Was the "Ensure open cursor is killed before finishing an iterator with limit. Issue reported by Andrew Bonventre." Supposed to close cursers after they have been used?

I noticed this issue just yesterday saw this update and rebuilt my application with the new libraries. However our database machines are still left with hanging timed out cursors (approx. 10 minutes after the query was made)?

Mon Jan 28 17:12:37 [conn1195798] killcursors: found 0 of 1
Mon Jan 28 17:12:37 [conn1195798] ClientCursor::find(): cursor not found in map 2885915363044502177 (ok after a drop)
killcursors: found 0 of 1
Mon Jan 28 17:12:38 [conn1195798] killcursors: found 0 of 1
Mon Jan 28 17:12:39 [conn1195793] killcursors: found 0 of 1
Mon Jan 28 17:12:39 [conn1195793] killcursors: found 0 of 1
Mon Jan 28 17:12:39 [conn1195793] killcursors: found 0 of 1
Mon Jan 28 17:12:39 [conn1195793] killcursors: found 0 of 1
Mon Jan 28 17:12:39 [conn1195793] killcursors: found 0 of 1

We are iterating over an Iter object (http://pastie.org/5919597). I assumed the Iter object was closing its cursor, because the API does not let you do so manually. We also make calls to .One (err := ReadDatabase.C("pls").Find(bson.M{"_id":c}).One(result)).

Note that we hang on to our sessions. We create a session at the start of the processes and these processes are long running (they are replacing a service that would run for weeks), so we just hold onto the session object and don't close until a quit message is received.

Gustavo Niemeyer

unread,
Jan 28, 2013, 8:24:56 PM1/28/13
to mgo-...@googlegroups.com, golan...@googlegroups.com, mongod...@googlegroups.com
P.S. I'll move the thread to mgo-users only on the next reply, to
avoid the cross posting. If someone wants to follow, please move
there.

On Mon, Jan 28, 2013 at 9:38 PM, Nimi Wariboko Jr <psni...@gmail.com> wrote:
> I noticed this issue just yesterday saw this update and rebuilt my
> application with the new libraries. However our database machines are still
> left with hanging timed out cursors (approx. 10 minutes after the query was
> made)?
>
> Mon Jan 28 17:12:37 [conn1195798] killcursors: found 0 of 1

Are you actually seeing any issues? The message above isn't an
indication of an actual problem by itself. If you're holding logic for
more than 10 minutes, it is possible that mgo will try to kill a
cursor that is already dead due to a timeout on the server side. This
is fine, and so is the rest of your description.

There is also at least one other situation where I want to improve
cursor handling in a future release, but that's not it.


gustavo @ http://niemeyer.net
Reply all
Reply to author
Forward
0 new messages