Angry Erlang Rant

YOU WILL REGRET THIS!
My Other Mood is 'Even More Angry'

Friday, June 10, 2011

I'M GONNA TELL YOU A STORY
In which I tell you how to behave
- how dare I?


SOCKET.IO-ERLANG

• Developed by Yurii Rashkovskii, Omar Yasin, Fred Hebert (me)

• Used as a base demo app for this presentation

• Allows to write neat front-ends for conversational websites


BIZARRO SOCKET.IO-ERLANG

• 'Bad' socket.io-erlang used for the presentation

• Freely substitutes dependencies and actual code for whatever
purpose I have


APP STRUCTURE


APP STRUCTURE
Bunch of supervisors


APP STRUCTURE

web server


APP STRUCTURE

transport handlers
web server


APP STRUCTURE
Client code
attaches here
transport handlers
web server


WE USE A WEB SERVER

• We need a web server (the slide's title says just that (and also
the previous slide))

• Oh, Carrying parameters and a connection around is
annoying!

• Let's use parametrised modules!


PARAMETRISED MODULES

-‐module(test_module,
[Param1]).
some_method()
-‐>
Param1.

Equivalent to:

-‐module(test_non_pmod).
some_method(Param1)
-‐>
Param1.



1> X = test_module:new(horror),
X:some_method().
horror

2> test_non_pmod:some_method(sane).
sane



• They are great!

• We can use them as if they
were objects!

• They let us carry everything
as one large parameter!

• Let's do this!


I'LL TELL YOU WHAT

3> dbg:tp({X, some_method, 0}, [...]).
** exception error: no case clause matching
{test_module,horror}

4> dbg:tp({test_module, some_method, 0}, [...]).
* never matches anything *

5> dbg:tp({test_module, some_method, 1}, [...]).
* will actually match stuff *


What is this I don't even...


I'LL TELL YOU WHAT

• The parameters are global and they ghost values, become implicit
function arguments. Errors out of nowhere.

• They're based on a old fun hack ({Mod, Fun}:(Args))

• They mess up the concept of arity

• They mess up tracing (previous slide!)

• They were added because some library accepts callback modules and
nothing else but might still need state around. No other reason.


I'll use them anyway
(in my server)


YOU PROBABLY SHOULDN'T
But you might not have a choice, so let's keep going


WHAT ELSE DO WE HAVE?

•A supervision tree, of course!

• Some of the supervisors are tricky and must interact with
servers and dynamic children and ...

• Who starts who? By which API?

• We could probably just forget about supervisors, link stuff
together and make it simpler

• Let's do this!


IN THIS VERY SLIDE I PRETEND
I MAKE THE CHANGES

APP STRUCTURE
transport handlers
were moved and no
longer need a supervisor.
They only use links.

The code is more
straightforward!


What?
... my code is so much easier to read now!


I'LL TELL YOU WHAT

• You need to add ad-hoc start/restart policies and make sure
orderly shutdowns work ﬁne with just links. Care to add tests?

• You can no longer beneﬁt from systool's application upgrades
and downgrades as they depend on supervisors

• You will need to take your app down!


It's okay, I'll do rolling upgrades
through all nodes
this should avoid downtime


NOT WITH LIVE SESSIONS!
Nobody likes to be disconnected during a conversation!
Would you disconnect this guy?


Stolen from Yurii's talk earlier today

NOT WITH LIVE SESSIONS!
Nobody likes to be disconnected!


You're killing me. I'll leave the
change in. Code is meant to be
read ﬁrst!


OK, AS LONG AS YOU LISTEN
TO THE NEXT POINT

SURE, I'M HAPPY
WITH MY APP

• It's all done in OTP

• Now Easier to read

• Uses parametrized modules, hell yes!

• It's time to start it!

• Let's do this!


THIS IS GONNA BE FUN
main(_) ->
appmon:start(),
sasl:start(normal, []),
socketio:start(normal,[]),
{ok, Pid} = socketio_listener:start([
{http_port, 7878},
{default_http_handler,?MODULE}]),
EventMgr = socketio_listener:event_manager(Pid),
ok = gen_event:add_handler(EventMgr, ?MODULE,[]),
receive _ -> ok end.

And it works!
(believe me)


YOU, AGAIN!?
You are worse than clippy
What is it this time?


I'LL TELL YOU WHAT

• The VM starts all applications under the Application Controller

• Starting one outside of it means it is not supervised by it

• No app failure strategy (permanent, transient, temporary)

• No access to 'env' variables

• No respect of start phases
or dependencies


AND IT GETS WORSE
• With bad default values (or overly defensive code) for env
variables, bad things happen...

• In this case, inﬁnitely many web sockets opened for each client
(before a patch to change that, because I forgot to listen to this hint)


DO THIS INSTEAD
main(_) ->
appmon:start(),
application:start(sasl),
application:start(misultin),
application:start(socketio),
{ok, Pid} = socketio_listener:start([
{http_port, 7878},
{default_http_handler,?MODULE}]),
EventMgr = socketio_listener:event_manager(Pid),
ok = gen_event:add_handler(EventMgr, ?MODULE,[]),
receive _ -> ok end.

And it works better!
(believe me)


RIGHT
Your OTP code is not worth much without that


One more
thing...


DON'T LISTEN TO ME
If your product might not ship because of this.
Making it work is #1. Making it pretty is not.

HAPPY HACKING
Hopefully you won't regret this


Angry Erlang Rant

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Angry Erlang Rant

Similar to Angry Erlang Rant (20)

Recently uploaded

Recently uploaded (20)

Angry Erlang Rant