[erlang-questions] inets service startup

[Serge]

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.

>> Given that if you make your custom application that owns the httpd 
>> instance 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?

Serge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tar.gz
Type: application/x-gzip
Size: 2310 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070414/252998cb/attachment.bin>