Log file Viewer
#mongodb logs for Sunday the 14th of February, 2016
[00:06:07] <joannac> kryo_: i don't understand the question. Why can't you just index fieldName.obj ?
[00:36:46] <zamnuts> mongodb v3.0.8, nodejs driver v2.0.55: cursor.count never invokes callback: cursor.find(true,function(err,count){/* never gets here */}); cursor server = null, cursor connection = null, but cursor find query is _correct_ any ideas?
[00:38:55] <zamnuts> StephenLynx, 2.0.55 is the latest 2.0 patch version, i've tried updated to 2.1.7 but other queries aren't working as expected, level of effort is too great to upgrade minor versions right now
[00:42:12] <zamnuts> also, i can't reproduce this locally, only in prod, which is making this more difficult to troubleshoot
[00:42:48] <zamnuts> already double checked deps and versions on both envs for nodejs engine, npm package versions, etc.
[00:46:25] <zamnuts> I'm more or less wondering if anyone else has had this problem before and what they did to resolve it
[00:47:42] <zamnuts> i checked db.currentOp(); and the count is not present, just the normal local.oplog.rs stuff
[00:48:35] <zamnuts> yup yup, only difference is one is from the application, and one is from the mongo shell
[00:50:13] <zamnuts> it seems like the cursor.count never sends data over the wire, like i said above, cursor's server and connection are both null
[00:51:16] <kryo_> StephenLynx: mongoose seems a whole lot better than the standard nodejs driver, what would you reccommend instead?
[00:56:05] <StephenLynx> but since the node community is full of dumbasses, they fall for the meme and sacrifice performance in the process.
[00:56:38] <zamnuts> StephenLynx, nesting w/ callbacks != nesting w/ fors/ifs... closures being the major difference
[00:56:54] <kryo_> but i had a friend that used the mongo driver, while i used mongoose, seperate projects
[00:58:47] <zamnuts> kryo_, the standard driver is _not_ recommended in PHP... use PDO as your minimum integration point
[00:58:59] <StephenLynx> they can't build software that doesn't require a whole cluster for the life in them
[00:59:25] <kryo_> honestly i find php frameworks like laravel/symfony really nice, the bloat is kinda worth it
[01:03:24] <zamnuts> any clue as to where i can get a changelog for the native nodejs mongodb driver changes from 2.0 to 2.1? not finding anything...
[01:03:33] <kryo_> i'm at the point where i know laravel well enough that i'm not bothered by the lack of documentation though
[01:06:48] <zamnuts> omg "Implements the new GridFS specification" ...i'm screwed, this is going to be like a crate full of cans of worms.
[01:09:09] <kryo_> after working on ES6 code for a while the amount of times the word "function" appears in my code is starting to make me sick :P
[01:09:36] <zamnuts> StephenLynx, we've been over "promises are crap" i was just responding to "solution for the amount of callbacks"
[01:12:36] <kryo_> i didn't pay much attention to the code style since i'm trying to write it quickly
[01:15:40] <StephenLynx> if your top function were to take a callback to it, you could remove one callback, at the end
[01:15:56] <StephenLynx> because the thing that called this function could handle the callback of the last function that takes a callback
[01:17:02] <zamnuts> kryo_, the point is, if you set up your error handling correctly in Transaction/Balance, you don't have to handle each error individually
[01:18:20] <kryo_> but i guess i could just look at the stacktrace to find the line that caused the error
[01:18:49] <StephenLynx> https://gitgud.io/LynxChan/LynxChan/blob/master/src/be/engine/domManipulator/static.js#L367
[01:19:12] <zamnuts> if you attach a specific error code to your error object when it is created, then you can use at as a lookup in a hash table or something for UX/UI side of things if that is applicable
[01:19:32] <StephenLynx> so this function doesn`t have to handle the error from that, the thing that called this function handles that error
[01:27:51] <zamnuts> kryo_, yw, just a diff way to think about it, many people frown on the use of that async module in favor of promises although it is still maintained and improved upon
[01:54:58] <rpdprd> so I'm using genghis, and I have a field named "default". Unlike the other fields which simply appear as fieldName without quotes, default appears as "default" with quotes. Any idea why this is?
[01:57:30] <rpdprd> yeah, it seemed a bit odd because in mongo shell, the "default" field name doesn't appear any differently. maybe it's something json/javascript related
[01:57:41] <rpdprd> as long as mongodb doesn't have an issue with field named "default", I'm not concerned
[02:00:23] <rpdprd> thanks. I didn't think so either. it just seemed like a weird thing for genghis (running on PHP) to do. I'm going to stop using it sooner or later so it's not a big deal
[02:02:28] <rpdprd> maybe related to http://stackoverflow.com/questions/18934493/how-do-i-set-default-value-of-an-integer-in-mongodb?
[02:03:26] <rpdprd> genghis on the other hand runs on php, so I'm not sure how to explain that. working fine on terminal for me as well
[02:05:09] <rpdprd> thanks. https://docs.mongodb.org/manual/reference/limits/ also doesn't mention "default" as some reserved keyword, etc, so either i'll avoid it for now, or change it to something like "def" instead
[02:07:39] <rpdprd> genghis is a web interface (uses javascript), since default is a js keyword, it might be problematic with node and genghis
[02:56:25] <zamnuts> rpdprd, mongodb has no problem w/ the word "default" being a key in an object, even in standard js you could even write var a = {default:1} -- don't let bad syntax highlighters fool you
[03:03:28] <rpdprd> zamnuts: thanks. I looked into genghis and it seems to be something with javascript
[03:03:54] <rpdprd> or perhaps genghis. the json file of the data seems correct, it's probably genghis's problem
[03:03:59] <zamnuts> rpdprd, i'm curious as to what, i just scanned the src and couldn't find where it would be a problem
[03:04:29] <rpdprd> zamnuts: yea, I did the same thing, did a search for "default" in php, couldn't find anything constructive
[03:04:45] <rpdprd> zamnuts: same as the json served by the php server, so it makes me think it's something in the genghis frontend
[03:06:38] <rpdprd> {"count":1,"page":1,"pages":1,"per_page":50,"offset":0,"documents":[{"_id":{"$genghisType":"ObjectId","$value":"56bfed849287bf9fb9e5b05a"},"default":"hello world"}]} is the json document served by genghis, and nothing seems odd about the default field, so I suspect it's something in the frontend (that genghis fetches on demand from a cdn)
[07:54:35] <Drzoid> someone may guide me about setting up a one-collection replication from a master db to a new (empty) slave one ? (i'm too affraid to make mistake since english isn't my native language and i didn't understood the docs well ^^')
[11:59:25] <bilr> hello. Is there a dedicated channel for generic wiredtiger question? Is it ok to ask here if there isnt?
[13:04:44] <kurushiyama> I am currently reworking the spec files for the rpms. Is there a preferred branch I should work on? Currently, I am working on 3.2
[22:25:28] <pac1> Hello. I have cursor running in mongo shell, with an insert: d.forEach(function(x){ db.tokens.insert(x,{w:0})}). This runs very slowly. (about 1 insert per second.) No indexes on tokens. Why is it so slow?
[23:09:00] <jiffe> kurushiyama: I know what rollback means, I don't know why mongodb crashes because of this
[23:09:12] <Freman> CRITICAL - Memory Usage: 200.10GB resident, 368.34GB virtual, 178.31GB mapped, 356.61GB mappedWithJournal <- tbh, not even sure wtf
[23:10:13] <Gasher> I just wrote something to mongodb with mongoose and I got a field "__v" - what is it?
[23:10:13] <kurushiyama> jiffe: Well, wait a sec. Freman should be pretty easy to handle, then I will help you.
[23:12:06] <Freman> thanks, kurushiyama, it might not seem like it, but I do appreciate the help and info you guys offer up. I'm just getting tired of being lumped with the organizations mongo issues and wish they'd just hire someone that knew mongo (I'm closer to being a MySQL support engineer - a job I actually turned down before sun/oracle bought it than anything Mongo related)
[23:13:51] <kurushiyama> Gasher: Explains it pretty well: https://en.wikipedia.org/wiki/Optimistic_concurrency_control
[23:15:27] <kurushiyama> jiffe: Ok, here is what I would do: Create a backup of both an instance without the need to rollback and one of the instance which needs rollback (datafiles, if necessary)
[23:16:28] <kurushiyama> jiffe: Then, follow the procedure described here https://docs.mongodb.org/manual/core/replica-set-rollbacks/
[23:17:08] <Gasher> kurushiyama; I didn't understand much from that website... Should I just leave that field be?
[23:21:20] <jiffe> kurushiyama: so reading that it sounds like that is applicable if the rollback was already completed successfully
[23:21:42] <kurushiyama> Freman: Yes. Well, the memory surely is closing in at it's limits, but quite a bit away from being critical. What is the IOWait percentage? Use "top" on the machine to find a rough estimate. While at it, the system load might be helpful to determine wether you are in real trouble or not.
[23:22:37] <kurushiyama> jiffe: But you might want to inspect the according data, if created. If there is not anything to find. I'd resync.
[23:23:06] <Freman> systen load is 0.47 over 5 mins, and io is pretty close to idle - disk access is in kb/s
[23:23:08] <jiffe> kurushiyama: in my case the mongod is crashing before rolling back complaining about some inconsistent state
[23:23:45] <jiffe> I really hate resyncing, it takes a week+ to do a resync, I need to find ways to fix things without having to resync
[23:24:17] <Freman> Is now a good time to push the higher ups to let us upgrade and switch engines? :D
[23:25:31] <kurushiyama> jiffe: Well, that sounds about right about the duration. But the setup sounds rather strange.
[23:25:32] <Freman> yeh "top - 10:19:04 up 489 days, 4:33, 1 user, load average: 0.60, 0.48, 0.43" it's not doing much
[23:27:01] <kurushiyama> jiffe: Sounds like you missed the sweet spot for getting the most bang for the buck/server.
[23:32:18] <kurushiyama> Freman: To make a long story short: You wont get a suggestion on wether to migrate to WT or not. There are so many factors to be taken into account, this can easily take hours (and I make my living of those hours) ;)
[23:32:20] <jiffe> we used supermicro machines and seagate HDs so the machines came out to be pretty cheap
[23:32:20] <Freman> (yeh helps if you actually connect and ask it how it's configured vs going off overheard conversations.)
[23:34:16] <kurushiyama> Freman: My suggestion is to stay calm, and get yourself a decent MongoDB DBA *caugh* to review your setup and help you to decide on what actions need to be taken, if.
[23:35:10] <kurushiyama> Freman: As long as your disks are holding, the emergency plan should be to increase RAM, if that's feasible (calculate conservatively).
[23:43:22] <jiffe> the seagates are what killed us, they've been dying on us a lot lately, we're switching slowly to WDs
[23:44:27] <kurushiyama> There is a German joke about Seagate: "Sie geht oder sie geht nicht!" where "Sie geht" is pronounced (slightly incorrectly) like "Sea gate"
[23:46:33] <jiffe> heh, ok maybe not, back when I was in school my seagates never died when everything else seemed to
[23:48:58] <Freman> kurushiyama: yeh that'll be new boxes, I think those machines are fully populated.
[23:50:17] <Freman> thanks tho, did just have a chat with the cto (he walked in while I was talking to you) and he's going to get the guys using that db to go through and clean it up
[23:55:40] <Freman> so uh kurushiyama, as a certified fella, I wonder what your opinion is of this https://github.com/freman/queryguard (I know the best way would be to give them an interface so they don't touch the db, but devs are devs :()
[23:56:23] <Freman> I discovered I could abuse the bson sent in the packet to include extra detail in the currentOp()s
[23:57:19] <Freman> yeh that's done, this is to catch operator error (for something that they shouldn't even be doing)
[23:58:00] <Freman> I didn't want to touch $comment incase a dev was using it, I added another field and mongo seems to otherwise ignore it.
[23:58:22] <Freman> if it makes you feel better, any machine operations that connect don't go through this, it's only a human proxy