fireproofsocks
Mongo connection times out, but only when it is used by a dependency
I’m experiencing some odd behavior. I’m using mongodb_driver (v0.9.0) in an app (app1), and it’s been working great. But suddenly, when I use that app as a dependency (by app2), suddenly all my mongo queries time out.
My guess is that I’m stepping into something tricky with supervisors or something. (Why am I doing this? My thought was that app1 defines all the schemas and contexts for how to access resources, and I didn’t want to duplicate any of that in app2 – I want app2 to be ignorant about the “implementation details”).
app1 wraps the Mongo start like this:
def MyMongoWrapper do
def start_link(opts \\ []) do
# Read some config here... user, password, etc.
Mongo.start_link(opts)
end
end
which is ref’d in app1’s application.ex:
def start(_type, _args) do
children = [
{MyMongoWrapper, []}
]
opts = [strategy: :one_for_one, name: App1.Supervisor]
Supervisor.start_link(children, opts)
end
So all is well with the world in app1: I can start it up and make queries as expected.
But when I start working with app2 and I use app1 as a dependency, nothing seems to work, even though app1 DOES get started and the mongo process DOES get started.
Instead of relying on “implicit starting” (?) that happens when an app lists another app as a dependency, I tried manually listing App1 in app2’s supervision tree, but calls to Mongo still time out.
Likewise, if I remove all the children from app1’s application.ex and list the MyMongoWrapper in app2’s application.ex, I get the same result: any Mongo queries cause an exit due to timeout.
It’s really making me scratch my head and wonder why things are working in app1 at all. The config and everything seems to be exactly the same.
Does anyone have any ideas of what might be causing this type of behavior or other things I could check?
Marked As Solved
zookzook
The driver 0.9.2 does not support 4.0. Sorry, you need to downgrade the driver. It does not support AWS DocumentDB.
Also Liked
zookzook
I assume, your configuration is not working. Please turn on logging: GitHub - zookzook/elixir-mongodb-driver: MongoDB driver for Elixir, then you see more information about.
fireproofsocks
Thanks for the prompt reply @zookzook! This is interesting. I have verified that BOTH app1 and app2 have the IDENTICAL configuration options, something like this:
[
name: :my_mongo,
pool_size: 20,
url: "mongodb://:@localhost:/app1_dev",
timeout: 15000,
ssl: false
]
Note that the URL looks funny in dev because we don’t specify a user, password, port, or parameters (which do get set when connecting to a production mongo instance).
What is really curious is that BOTH app1 AND app2 show errors on startup when I set the config to include log: true:
10:13:33.630 [error] an exception was raised logging %DBConnection.LogEntry{call: :execute, connection_time: 5298000, decode_time: 6000, idle_time: 548338000, params: [], pool_time: 147000, query: %Mongo.Query{action: {:exec_hello, []}}, result: {:ok, %Mongo.Query{action: {:exec_hello, []}}, {%{"code" => 59, "codeName" => "CommandNotFound", "errmsg" => "no such command: 'helloOk'", "ok" => 0.0}, %Mongo.Events.CommandStartedEvent{command: :hello, command_name: :hello, connection_id: #PID<0.815.0>, database_name: "admin", operation_id: nil, request_id: 1}, 0, 5240}}}: ** (BadFunctionError) expected a function, got: true
(db_connection 2.4.2) lib/db_connection.ex:1532: DBConnection.log/2
(db_connection 2.4.2) lib/db_connection.ex:1510: DBConnection.log/5
(mongodb_driver 0.9.2) lib/mongo.ex:1526: Mongo.exec_hello/2
(stdlib 3.16.1) timer.erl:166: :timer.tc/1
(mongodb_driver 0.9.2) lib/mongo/monitor.ex:239: Mongo.Monitor.get_server_description/1
(mongodb_driver 0.9.2) lib/mongo/monitor.ex:164: Mongo.Monitor.update_server_description/1
(mongodb_driver 0.9.2) lib/mongo/monitor.ex:151: Mongo.Monitor.handle_info/2
(stdlib 3.16.1) gen_server.erl:695: :gen_server.try_dispatch/4
(stdlib 3.16.1) gen_server.erl:771: :gen_server.handle_msg/6
(stdlib 3.16.1) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
app1 throws 3 of these errors, and then they pop up intermittently, but app1 can go on to successfully issue commands, e.g.
# app1
iex> Mongo.insert_one(:my_mongo, "foo", %{what: "up"})
{:ok,
%Mongo.InsertOneResult{
acknowledged: true,
inserted_id: #BSON.ObjectId<633d93aac6e47b35cb0d1fc5>
}}
whereas app2 just throws an unending stream of these errors into the log. The same command on app2 yields a timeout:
# app2
iex> Mongo.insert_one(:my_mongo, "foo", %{what: "up"})
** (exit) exited in: GenServer.call(:my_mongo, {:checkout_session, :write, [write_counter: 1]}, 60000)
** (EXIT) time out
(elixir 1.13.4) lib/gen_server.ex:1030: GenServer.call/3
(mongodb_driver 0.9.2) lib/mongo/session.ex:142: Mongo.Session.start_session/3
(mongodb_driver 0.9.2) lib/mongo/session.ex:694: Mongo.Session.in_session/5
(mongodb_driver 0.9.2) lib/mongo.ex:1482: Mongo.issue_command/4
(mongodb_driver 0.9.2) lib/mongo.ex:849: Mongo.insert_one/4
It’s like Mongo “knows” how its server is getting started or something. Very curious. Any other ideas for what could explain this behavior?
I just noticed app1 shows "mongodb_driver": {:hex, :mongodb_driver, "0.9.1" in its mix.lock whereas app2 specifies "mongodb_driver": {:hex, :mongodb_driver, "0.9.2" … so I’m gonna suss that out
zookzook
If both apps have identical configurations then they started the supervisor related stuff twice. Use only one configuration. A topology should only started as a singleton.
fireproofsocks
Ok, we’ll pin it to v0.9.1. Thanks for the responses! They are much appreciated.
This really is a great driver – I’d love to see an Ecto adapter for it. We’ve got a handful of code that could maybe be adapted for that.
Interesting re DocumentDB: we are using DocumentDB in production with mongodb_driver v0.9.1 and it has been working fine – admittedly our queries are limited to mostly CRUD without a lot of filters or sorting, but it hasn’t had any issues.
zookzook
I committed a fix on the master branch. Feel free to test it. If it is working like expected, then I will draft a new release for the fix!
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
The deployment platform built for Elixir: PaaS ease, VPS control.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"