Liveview 0.18.0? about flame_on HOT 12 CLOSED

I've been working on it this week. I've got it upgraded locally, but I ran into some issues that I am still working through. I hope to have it done tomorrow or early next week.

from flame_on.

@TheFirstAvenger is this resolved yet?

from flame_on.

@aselder I have a branch with 0.18, would you have time to try it out and let me know if you run into any issues?

{:flame_on, github: "DockYard/flame_on", ref: "mb-liveview-0-18"}

from flame_on.

@TheFirstAvenger I'll try to give it a shot tomorrow.

from flame_on.

@TheFirstAvenger I downloaded and gave it a shot. It works on really simple pages, for instance a static asset being served by Plug.Static. However, once I get to anymore complicated pages, I'm getting GenServer time outs in the trace_started? function. I increased the timeout to infinity and added logging and I see lots of call to the function, but the call to GenServer.call never returning.

from flame_on.

It looks like we're blowing out the MessageQ of the capture server :) Then eventually cowboy terminates the connection and kills everything.

[error] Ranch protocol #PID<0.3624.0> of listener TenantWeb.Endpoint.HTTP (connection #PID<0.3623.0>, stream id 1) terminated
an exception was raised:
    ** (ErlangError) Erlang error: {:normal, {GenServer, :call, [FlameOn.Capture.Server, :trace_started?, :infinity]}}
        (elixir 1.14.2) lib/gen_server.ex:1038: GenServer.call/3
        (flame_on 0.5.2) lib/flame_on/capture/server.ex:28: FlameOn.Capture.Server.trace_started?/0
        (flame_on 0.5.2) lib/flame_on/capture/mock_function.ex:6: FlameOn.Capture.MockFunction.start_if_not_started/1
        (flame_on 0.5.2) lib/flame_on/capture/mock_function.ex:24: anonymous fn/3 in FlameOn.Capture.MockFunction.generate/3
        (cowboy 2.9.0) /Users/aselder/Development/vulcan/deps/cowboy/src/cowboy_stream_h.erl:306: :cowboy_stream_h.execute/3
        (cowboy 2.9.0) /Users/aselder/Development/vulcan/deps/cowboy/src/cowboy_stream_h.erl:295: :cowboy_stream_h.request_process/3
        (stdlib 4.2) proc_lib.erl:240: :proc_lib.init_p_do_apply/3

from flame_on.

@aselder Thanks for the update. Yes, I did see that crash last week, but then it seemed to not happen any more this week. I feel like there is a deadlock happening which is why the trace_started? call is hanging. I will dive in and take a look this weekend or early next week.

from flame_on.

@aselder I have a branch that reworks the trace issue, but as you pointed out the root cause is the message Q being overloaded. I enabled debug and it looks like it is spinning its wheels inside Jason.Decoder which was updated from 1.0.1 to 1.4 in this branch.

[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107380
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107381
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107382
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107383
[debug] flame_on trace: call {Jason.Decoder, :"-string_decode_function/1-fun-0-", 1}, stack_size: 107384
[debug] flame_on trace: return_to {Jason.Decoder, :string, 6}, stack_size: 107385
[debug] flame_on trace: call {Jason.Decoder, :key, 6}, stack_size: 107384
[debug] flame_on trace: call {Jason.Decoder, :value, 5}, stack_size: 107385
[debug] flame_on trace: call {Jason.Decoder, :value, 5}, stack_size: 107386
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107387
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107388
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107389
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107390
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107391
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107392
[debug] flame_on trace: call {Jason.Decoder, :string, 6}, stack_size: 107393

Continuing to investigate.

from flame_on.

Confirmed that this also happens with Jason v1.2.

from flame_on.

Interesting. Reverting back to 1.0.1 still results in this behaviour. I wonder if this is showing up now due to an Erlang version difference? I believe I was on OTP 22 or 23 when initially developing this, I am on 25 now. Will continue to investigate.

from flame_on.

I was able to reproduce the issue with OTP 23. So far I am not able to find a combination that doesn't trigger this. Ideally I would like to test this issue on a project with the main branch of Flame On (0.5.2) after reproducing it with that same project running this liveview branch. That would tell us if the issue is this branch or if this was an always-existing thing. The problem is that I can't run 0.5.2 on any of my current projects as they are already LiveView 0.18.

I think what I am going to do at this point is merge this PR and the other two into main, and start then work on digging into the specific issue moving forward, since trying to determine if/when it started isn't proving fruitful.

from flame_on.

I have opened #26 to track the overloading issue. Note that #24 changes the initial failure we were seeing from a 5 second GenServer timeout to a hanging no response scenario, which is a worse user experience, but will help us diagnose and resolve this issue. I am not planning on publishing a new version of Flame On till we resolve this issue.

from flame_on.