Ability to turn off Auto Reconnect in emongo_pool

[jdhood1]

Hey Oleg,

I have a requirement to let the application die if it cannot connect to or loses its connection to the DB. That way another program can report that problem to a UI and restart the application. The only way I could think of to do that was to add the ability to turn off auto reconnect in emongo_pool. That causes the emongo_sup to retry starting it a few times and then give up. That causes the app to die, which, in turn, causes my app to die because I started emongo with the Type field to 'permanent'. If there's a better way, please let me know.

I also noticed a bug with find_and_modify's 'fields' option. I noticed and removed an unused function in the performance test I recently added.

Jeremy

[master]

Have you seen Erlang supervisor maximum restart frequency? http://www.erlang.org/doc/design_principles/sup_princ.html#frequency "If more than MaxR number of restarts occur in the last MaxT seconds, then the supervisor terminates all the child processes and then itself." Perhaps, it's a feature which you're looking for.

[jdhood1]

You're right. It would have been way better to just make those configurable.

I started looking at the performance test I added more carefully because I was seeing some strange behavior in my applications. I was only checking to make sure the "err" value returned was null. However, when I started checking "n", the results were different. For an update_sync and delete_sync, I'd expect "n" to be 1 because 1 existing entry was modified. However, for insert_sync, it should be 0. Once I started checking "n", I realized that the messages to the DB and their responses were getting mixed up. For example, an update_sync response was being treated as an insert_sync response. I looked through the code for a couple of days, on and off, and even had one of my coworkers look at it with me for an entire day! We couldn't see anything that would have caused this behavior. The ReqId seemed to assigned and handled properly, parsed out of the response properly, etc. It wouldn't fail every time either. Out of the 500 processes running 10 tests each (5,000 tests total), only about 4-10 would fail. The failures would sometimes domino as well. For example, if the insert_sync got a response before the data was really inserted, the next command that expects the data to be in the DB would sometimes fail because the data wasn't there yet.

I'll push the new version of the performance test so you can see what I'm talking about. I vaguely remember having this problem a while back with Jacob's branch, so I don't think it's anything you introduced. If it's not a priority to you, then don't worry about it. I reverted back to my other version of Emongo that I merged off of Jacob's latest a while back. I added find_and_modify, all the *_sync functions, and some other stuff. I was in a time crunch and couldn't spend more time on this problem and had to get past it ASAP. I'll get the version I'm using up to github soon, if you're interested in having a look at it.

Thanks again for your responsiveness. It's great to having other Erlangers out there to talk to. We are few and far between, at least where I work.

Jeremy