Comments on: Erlang Pattern: The Router

By: kevin

kevin — Mon, 19 Oct 2009 21:47:25 +0000

@Dizzy – I’ll have to think about this a bit. I knew going into this that we’d get bogus timeout messages but for what we were doing that was acceptable. We have fairly robust logging so between the data in the message and the log output we can debug timeouts.

@Hunter – The lookup was a simple ETS table which contained some metadata about the service (interface version, acceptable messages, etc). We used monitors to determine when to remove a service and judicious use of pg2 to sync up information across the cluster.

By: Hunter Morris

Hunter Morris — Mon, 19 Oct 2009 21:14:41 +0000

I like this.

What was the lookup mechanism in the recent implementation you talked about? I’m interested in how the “target” processes notify the lookup bookkeeping about their deaths.

By: Dizzy

Dizzy — Mon, 19 Oct 2009 19:49:48 +0000

I’ll admit that this pattern bugs me a bit. The root of my discomfort is the fact that you’re doing a gen:call on the router process, which causes the caller to setup a monitor on that (router) process. However, what we REALLY want to monitor is the target process. After all, if the target crashes, we’ll never know how/why — we’ll just get a timeout from the router, which is misleading to say the least.

So there are two options, I suppose:
1. Do a call to get the target PID, followed by a call to that process
2. Do a cast to the router which in turn does a cast to the target

The downside with 1 is increased latency (likely). However, you get more meaningful errors, which in my book, is worth a bit of latency. Option 2 makes it impossible to know if the router or target actually recv’d the message.

A third option would be to split the difference like so:
1. Setup monitor on router
2. Cast request to router
3. Recv status notif from router with target pid
4. Setup monitor on target (delete router monitor)
5. Recv completion notice from target

This way you would know where the message fails, with slightly better concurrency. But you’d have to show me a pretty convincing chunk o’ profiling to justify that over option 1. :)

My $0.02. :)