[erlang-questions] inets service startup

Ingela Anderton Andin ingela@REDACTED
Mon Apr 16 10:15:03 CEST 2007

Serge wrote:
> Ingela Anderton Andin wrote:
>> Serge Aleynikov wrote:
>>> Ingela Anderton Andin wrote:
>>>> [...]
>>>>> I was poking around through inets code, and there turns out to be 
>>>>> an option in httpd.erl for starting httpd service by hooking it up 
>>>>> to a custom supervisor (httpd:start_link/1).  This seems to solve 
>>>>> the second problem I had of being able to separate a critical 
>>>>> httpd service from the other ones managed by inets.
>>>> Well yes there is such an option,  starting it this way however 
>>>> will make the http-server part
>>>> of your application instead of the inets application and you can 
>>>> for instance no longer utilize soft upgrade for the inets application. 
>>> I might be wrong with the resulting conclusion, yet it seems to me 
>>> it should work.  In order to start an httpd instance this way, it 
>>> would still require inets to be started.
>> No unfortunately not. The httpd instance will be hung under the 
>> process that called start_link.
> Well, that's what I originally thought before I found the 
> httpd:start_link/1, but in practice httpd instance won't start without 
> inets started even if hung under a different application's supervisor.
> Extract the attached tarball, and do:
> $ cd test
> $ make
> $ make run1
> This will start httpd instance.
> $ make run2
> This won't start httpd instance.
> The only difference in two releases is the presence of inets application.
As you are running in embedded mode you do not have dynamic code loading 
and hence the inets
code is not loaded,  when you have not listed inets  as an application 
to start. That is why  you can not  start the  orphaned httpd server 
without starting the inets application in your scenario.

>>> Given that if you make your custom application that owns the 
>>> htstance dependent on inets (i.e. include inets in the 
>>> 'applications' section of the *.app file), wouldn't release handler 
>>> be able to do a soft upgrade of inets by restarting your custom app 
>>> together with the httpd instance?  Or this wouldn't classify as a 
>>> truly soft upgrade?
>> As the httpd instance is not hanging under the inets supervison tree 
>> it can not be softly upgraded.
>> Restarting processes is not a soft upgrade, a soft upgrade is when 
>> processes are suspended new code is loaded, code_change functions are 
>> run and then  the processes are resumed
>> and can continue where they left of.
> Well, I was referring to the soft-upgrade of inets *itself*.  If 
> there's an orphaned httpd server hung elsewhere and inets application 
> is started and upgraded, would that orphaned httpd instance prevent a 
> soft upgrade of inets itself?
No it should not prevent it.
But upgrading inets twice ought to crash the orphaned server as its 
code-instance would no longer exist.

Regads Ingela - OTP team

More information about the erlang-questions mailing list