[erlang-questions] Erlang newbie questions

[Gerry Weaver]

Hi Garrett,

Thanks. I will look into the items you mentioned. 


BTW:  If I were to rework the start up code, I certainly wouldn't do so in a vacuum. I would solicit feedback from the community. It would be very sad if others were not able to benefit from the effort. I'll let y'all know when I decide what to do.


Thanks,
-G 



-----Original Message----- 
> From: "Garrett Smith" <g@REDACTED> 
> To: "Gerry Weaver" <gerryw@REDACTED> 
> Cc: erlang-questions@REDACTED 
> Date: 10/21/11 14:29 
> Subject: Re: Re[2]: [erlang-questions] Erlang newbie questions 
> 
> On Fri, Oct 21, 2011 at 2:04 PM, Gerry Weaver <gerryw@REDACTED> wrote:
> > Hi Garrett,
> >
> > I write software primarily for banks these days. There are some fairly rigid requirements when it comes to management and monitoring. Applications that start daemon processes from within other daemons processes without dropping a pid file (Unix) for each, are a problem.
> 
> This is a relatively common problem with apps in general. Java, for
> example, doesn't support this in the typical JVM implementations --
> you need something like jsvc for running as a daemon.
> 
> os:pid/0 will give you the pid for the Erlang VM process, so you could
> do this in user space.
> 
> I use run_erl to run Erlang. This doesn't plug into typical watchdog
> apps, which look for pids, but it provides a way to communicate with
> Erlang (using to_erl) without using distributed Erlang. I've used this
> technique extensively and find it robust.
> 
> > Windows software virtualization products have the same issue with regard to services. For example, on Unix, when the Erlang VM starts it starts epmd.
> 
> This is true only when you start Erlang in distributed mode.
> 
> I wholeheartedly agree that epmd is problem for highly controller
> environments. I don't use distributed Erlang for that reason, among a
> few others.
> 
> > I didn't see a pid file for either of these. If epmd dies, the VM process will restart it and vice versa. There would need to be pid files created by this case as well. Basically, there would need to be some rework of the start up code. If this were to be reworked, it would make a lot more sense to me to just have these daemons start separately. When it comes to the mutual restarting business, it would be better to have a separate watchdog process for that. This way if monitoring software is in use, it would fill the monitoring roll and the watchdog process would not need to be started. I also see a major benefit to having the ability to start/control Erlang from within another application, so it would make sense to add that feature, if one was already reworking the code.  I hope this makes sense.
> 
> I understand your concerns, but I'm not sure there aren't good ways to
> deal with them, even for demanding clients.
> 
> In any event, this thread has provided a lot of great discourse.
> Thanks for posting and good luck!
> 
> Garrett
> 
> >
> >
> > Thanks,
> > -G
> >
> >
> >
> > -----Original Message-----
> >> From: "Garrett Smith" <g@REDACTED>
> >> To: "Gerry Weaver" <gerryw@REDACTED>
> >> Cc: erlang-questions@REDACTED
> >> Date: 10/21/11 10:01
> >> Subject: Re: [erlang-questions] Erlang newbie questions
> >>
> >> Hi Gerry,
> >>
> >> On Thu, Oct 20, 2011 at 4:30 PM, Gerry Weaver <gerryw@REDACTED> wrote:
> >> > Hello All,
> >> >
> >> > Please disregard the questions in my previous two posts. I have managed to find the answers that I was looking for.
> >> >
> >> >
> >> > Sam made an interesting point with regard to the Unix daemon behavior. This prompted me to dig into to the code a bit more. I'm afraid this would prevent me from using Erlang for any upcoming projects.
> >>
> >> Out of curiosity, with respect to daemon behavior, what requirements
> >> do you have that can't be met?
> >>
> >> Garrett
> >
> >
> >
> >