Code Review Request: Genserver stuff for site activity

Chat / Discussions
1

Hey folks, recently wrote up a few agents and genserver designed to handle recent site activity such as recent posts, upvotes, replies to your posts, pings from users and such. A nice fellow on reddit gave me a code review which got me a little deeper into OTP concepts so I did a rewrite that is definitely better than what I had. Still much to learn though so if anyone is interested I would love a design and code review of the new iteration.

Le codes: https://github.com/smileys-tavern/smileys_data/tree/master/lib/state

Here is what changed from my original design:

  • added supervisor for each style of bucket (buckets are agents or genservers depending on needs)

  • using simple one for one strategy

  • ditched some registries and added each bucket to a global registry maintained via syn (mnesia based) with a strategy of staying dead when crashed/killed. This is to keep imprint smaller since if there is any new activity a new bucket will be created

  • implemented a protocol that provides a uniform interface to all activity (I dont like it’s name so far, but its working well in terms of simplifying use for the client)

There’s a couple event expireys I’ve yet to implement in there and a couple of my own concerns but I’ll leave it at that for now. Happy to answer any questions about usage I missed

1 Like
2

Thought it worth a mention that there turned out to be a fairly bad bug in that code. Symtoms included working fine testing on a single node, and intermittantly crashing when upon updates in a distributed env for update that involved an expirey.

Turns out Process.send_after (and the underlying erlang function) only finds local processes by their pid/atom name. Since the processes I’m expiring are registered globally via mnesia there was a better than even chance they’d live on a different machine.

The solution I implemented for now is a genserver responsible only for expiring events. One of those is running as a worker on each node. That way whatever machine happens to hold the process will have the expirey timer process assigned to it. Glad the client for all this is behind a protocol, made the expirey server dead simple.

Reading a few chapters out of erlang and otp in action has helped brush up but practicing is definitely helpful… still think there are nicer solutions for some of this stuff