[erlang-questions] time consuming operations inside gen_server

[Max Lapshin]

Call is a throttling and overload control mechanism.

If your worker is too slow you will ruine your erlang vm with several
millions of casts in the message box

On Wednesday, December 12, 2012, Martin Dimitrov wrote:

> Hi,
>
> This is actually a cast but since it takes long the gen_server will be
> blocked and I want to avoid this.
>
> Thanks for the replies,
>
> Martin
>
> On 12/12/2012 12:04 PM, Max Bourinov wrote:
> > Hi Martin,
> >
> > First of all I try to avoid calls in my systems. I believe that is there
> is
> > a call - there is a potential lock. Casts are friends.
> >
> > In your case I would suggest you to have "special" workers for time
> > consuming operations. Workers should be gen_servers and should be a part
> of
> > your supervisors tree.
> >
> > This is just a general suggestion - of course each case is unique. Please
> > adapt it to your case if possible.
> >
> > Best regards,
> > Max
> >
> >
> >
> >
> > On Wed, Dec 12, 2012 at 1:46 PM, Martin Dimitrov <mrtndimitrov@REDACTED<javascript:;>
> >wrote:
> >
> >> Thanks, this sounds very cool.
> >>
> >> On 12/12/2012 11:42 AM, Attila Rajmund Nohl wrote:
> >>> 2012/12/12 Martin Dimitrov <mrtndimitrov@REDACTED <javascript:;>>:
> >>>> Hi all,
> >>>>
> >>>> In our application, we have a gen_server that does a time consuming
> >>>> operation. The message is of type cast thus the caller process doesn't
> >>>> sit and wait for the operation to finish. But while the gen_server is
> >>>> busy with the cast message, it doesn't serve any other call, right?
> >>>>
> >>>> So, would it be appropriate to create a process that will do the time
> >>>> consuming operation and then notify the gen_server?
> >>>
> >>> The pattern I use in this case is to still use gen_server:call (if the
> >>> caller needs to be blocked), start a separate process for the
> >>> time-consuming stuff, return {noreply, ...} from the handle_call (so
> >>> the gen_server can handle other calls), then call gen_server:reply
> >>> from the started process when the time-consuming operation finished.
> >>> Of course, the applicability of this pattern depends on what you
> >>> actually do.
> >>>
> >>
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED <javascript:;>
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <javascript:;>
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121212/b2693846/attachment.htm>