[erlang-questions] Writers Readers problem

[Garrett Smith]

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