synchronous diameter_app:handle_request() -- how to spawn a worker?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

synchronous diameter_app:handle_request() -- how to spawn a worker?

Anders G S Svensson
Each handle_request callback happens in a process that's spawned for
that purpose, so concurrency is already there. You can do what you
want in the callback as long as it (eventually) returns an answer (or
not).

Or are you looking for more control over the request processes?

Anders



[hidden email] writes:

> Date: Mon, 03 Jul 2017 02:07:52 +0200
> From: Rick van Rein <[hidden email]>
> To: Questions erlang-questions <[hidden email]>
> Subject: [erlang-questions] synchronous diameter_app:handle_request()
> -- how to spawn a worker?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> I built authorisation code in Erlang, and am now trying to put Diameter
> in front of it.
>
> The code takes a fair bit of data and time, so I am preparing to split
> the data over nodes and redirect requests with Erlang's builtins, at the
> same time monitoring it for high availability.
>
> In diameter_app however, the handle_request() callback wants a final
> response.  Deferring it with "noreply" is not mentioned as an option.
> Is there another way to initiate concurrency in handling requests?
>
> Thanks,
>  -Rick
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: synchronous diameter_app:handle_request() -- how to spawn a worker?

Rick van Rein
Ah!

> Each handle_request callback happens in a process that's spawned for
> that purpose, so concurrency is already there.

That makes sense!  I seem to have misread the diameter documentation to
suggest that it would setup a diameter_app for each transport connection.

It probably was the phrasing under {restrict_connections,...} or
{share_peers,...} that got me to hold the wrong end of the stick.

> You can do what you
> want in the callback as long as it (eventually) returns an answer (or
> not).

Clear.

> Or are you looking for more control over the request processes?

No, this is all that I needed.  Proper understanding :)

Thanks!
 -Rick
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...