elixir-ecto/connection

Connection behaviour for connection processes

connection's Issues

handle_continue equivalent

In GenServer since OTP21 or so, there's a handle_continue callback for allowing asynchronous startup without accepting external messages until a required step or two are completed. Connection is meant to be a superset of GenServer functionality, and I suspect was originally motivated by the lack of handle_continue-like functionality in older GenServer versions, but does not (yet?) implement a handle_continue callback.

I have a scenario in which the Connection isn't truly "ready" to use until two TCP handshaking events are completed after establishing the initial gen_tcp connection.

the flow is basically like this:

1. :gen_tcp.connect/4
2. send a tcp message to a device to "register" a session
3. The device sends a response, which I then parse and modify state using handle_info({:tcp, socket, message}, state)
4. I then send another tcp request to request device metadata
5. The device sends a response, which I then parse and store in state as well. At this point, my connection is ready to handle additional messages from any client.

I don't want to block start_link/init by waiting until this handshake is completely finished, because I start multiple connections of different types in the process supervision tree, so the normal async startup that Connection offers is desirable. But I also want to make sure these two handshaking events happen before I start allowing Elixir code to send messages to the connection.

Is there an "idiomatic" solution for this kind of multi-step connection situation in Connection? Obviously it's not quite :backoff but it's not exactly :ok in steps 1-4 above, but synchronous mode isn't quite a natural fit either.

I was originally planning on faking it with Process.send_after/3 and some curt replies to clients that try to do things before the handshaking is done. I see that Ecto's DBConnection uses Connection with a cast to self() to handle a sort-of similar set of issues.

Does it conceptually make sense to add handle_continue to Connection? I may be able to get around to putting together a PR for that if there's a sense that it's desirable, though I'm a bit worried about the added complexity with the various interactions between states that Connection supports.

Connection warrning while compilation time

Version: 1.1.0

Hi Connections, I'm getting a bunch of warnings when we're trying to compile it for release. I tried to investigate on pointed file and turned out it's the same as what been suggested in warnings message.

Logs:

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:429

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:431

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:491

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:540

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:581

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:625

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:628

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:631

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:657

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:660

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:663

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:744

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:770

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:813

Dependencies:

defp deps do
  [
    {:phoenix, "~> 1.5.1"},
    {:phoenix_pubsub, "~> 2.0"},
    {:phoenix_ecto, "~> 4.0"},
    {:ecto_sql, "~> 3.0"},
    {:postgrex, ">= 0.15.0"},
    {:phoenix_html, "~> 2.11"},
    {:jason, "~> 1.1", override: true},
    {:poison, "~> 3.1", override: true},
    {:plug_cowboy, "~> 2.1"},
    {:ecto_enum, ">= 1.4.0"},
    {:argon2_elixir, "~> 2.0.5"},
    {:ecto_soft_delete, "~> 1.0"},
    {:elixir_uuid, "~> 1.2"},
    {:tzdata, "~> 1.1", override: true},
    {:timex, "~> 3.0"},
    {:ex_json_schema, "~> 0.7.3"},
    {:ex_phone_number, "~> 0.2"},
    {:httpoison, "~> 1.7"},
    {:scrivener_ecto, "~> 2.0"},
    {:sonix, "~> 0.1.0"},
    {:decimal, "~> 1.8"},
    {:misc_random, "~> 0.2.9"},
    {:quantum, "~> 3.0"},
    {:secure_random, "~> 0.5.1"},
    {:bamboo_smtp, "~> 3.0.0"},
    {:bamboo, "~> 1.5"},
    {:hackney, "~> 1.9"},
    {:telemetry, "~> 0.4"},
    {:countries, "~> 1.6"},
    {:opentelemetry, "~> 0.6.0", override: true},
    {:opentelemetry_api, "~> 0.6.0", override: true},
    {:opentelemetry_exporter, "~> 0.6.0", override: true},
    {:opentelemetry_phoenix, "~> 0.2.0"}
  ]
end

Target Command:

mix deps.get --prod && mix deps.compile && mix compile --force

Any other reason for the warning message?

Why :erlang.phash2(1,1)?

System.stacktrace is deprecated

And has been deprecated for some time now

==> connection
Compiling 1 file (.ex)
warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:429

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:431

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:491

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:540

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:581

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:625

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:628

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:631

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:657

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:660

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:663

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:744

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:770

warning: System.stacktrace/0 is deprecated, use __STACKTRACE__ instead
  lib/connection.ex:813

Implement child_spec/1 in __using__

I think it's necessary because use GenServer implements child_spec/1 and so should Connection do.

If you agree, I can implement the PR