[erlang-questions] Writers Readers problem

Garrett Smith g@REDACTED
Tue Jan 31 16:54:09 CET 2012

The process I have in mind is a very simple dispatch service. I'd be
surprised if that's a bottleneck. Maybe one token manager per core? ;)

If the tokens were more than just, well, tokens -- i.e. implemented
some behavior independent of one another -- I think one process per
token would make sense.

On Tue, Jan 31, 2012 at 9:31 AM, dmitry kolesnikov
<dmkolesnikov@REDACTED> wrote:
> Hello,
> With a registered process you have a single-server bottleneck, do not
> keep all eggs in one basket. What I mean is a process per token...
> In this respect, the process idles in memory unti it is consumed or
> ttl expired. You have to protect data against OOM or node failure. In
> this particular case for one-time token I would not see a strict
> requirements for durability and recovery due to cost and system
> complexity.
> But if you are strict about durability then DHT/Chord type of
> in-memory systems are required: mnesia, riak, etc.
> Best Regards,
> Dmitry >-|-|-*>
> On 31.1.2012, at 17.12, Garrett Smith <g@REDACTED> wrote:
>> On Tue, Jan 31, 2012 at 5:18 AM, Roberto Majadas Lopez
>> <roberto.majadas@REDACTED> wrote:
>>> 2012/1/30 Dmitry Kolesnikov <dmkolesnikov@REDACTED>
>>> The problem is that i've n process representing an user session, and the
>>> token is like a "ticket" to authorize to take some information from the
>>> server. The real user gets the token and goes to an http server (inside the
>>> erlang app) a create one of the (m)-process. This process needs to check if
>>> the token is valid or not. If is valid, the user can get the data and the
>>> token is removed.
>> This sounds like a registered process (e.g. gen_server) that manages
>> the token. It's user facing API might look like this:
>> acquire_token() -> {ok, Token} | timeout
>> acquire_token(Timeout) -> {ok, Token} | timeout
>> release_token(Token)
>> is_token_valid(Token) -> boolean()
>> The user processes would acquire a token and pass it to an agent,
>> which would then validate it before proceeding. The agent could
>> release the token when it was done with it.
>> This scheme could be used for rate limiting, simple authorization, etc.
>> This problem seems independent of persistence, independent of crash
>> recovery. If you needed to recover token state from a crash, the
>> process would need to save off its state somewhere (I typically use a
>> single dets table per process) and look for that state on init.
>> Garrett

More information about the erlang-questions mailing list