Age | Commit message (Collapse) | Author |
|
|
|
It was possible to insert {Mod::atom(),Vsn::term()} instead of
Mod::atom() in the modules list in a .app file. This was not visible
in the documentation of .app files, but it was visible in the
documentation of application:load/[1,2] (where the .app file term can
be used directly as first argument).
The Vsn part was never used, so this possibility has now been removed.
|
|
The test is added in release_handler_SUITE since this makes it
possible to test the full upgrade instead of just a simple library
test of supervisor:code_change.
|
|
Changes to the mechanism for upgrading the emulator in OTP R15 was
erronously not handled in release_handler:upgrade_app, downgrade_app,
upgrade_script and downgrade_script. This has been corrected,
including test and documentation.
|
|
* jw/release_handler_1:
General improvements to release_handler_1:get_supervised_procs
Conflicts:
lib/sasl/src/release_handler_1.erl
lib/sasl/test/release_handler_SUITE.erl
OTP-9546
|
|
The core issues this patch attempts to solve is two fold, 1) have
release_handler_1 act slightly differently in two corner cases and 2)
clean up the code in get_supervised_procs/0 to remove nested cases and
etc.
Regarding #1, get_supervised_procs/0 will now call functions to
test to see if the supervisor is suspended before attempting to ask it
for a list of children. It now will print an error message regarding
the suspended supervisor and produce an error that will cause the VM
to restart. Previously it would timeout attempting the call to
which_children and the VM would restart without any details regarding
the reason.
The second corner case is if in a child specification a supervisor is
incorrectly stated to be a worker and get_modules is called against it.
A timeout will occur causing a VM restart. Similar to the last corner
case in this patch an error message is printed and an error is emitted
causing a VM restart.
When first looking into the issue it was hard to discover why my
upgrades where failing. All I received during the upgrade process was
a timeout and a VM restart, no other information. This patch should
help users track down issues like these.
Regarding #2, due to the above confusion in trying to figure out what
had happened I dug into the code and started tracing it through and
found that the nested case statements and etc made it confusing. So I
started to rework and clean up, hopefully making this code path clearer
to future readers.
|
|
Given this option, all modules that are to be purged by indicated
upgrade,and that can be soft purged, will be purged when all other
check of check_install_release have been successfully completed.
I added a note under install_release in the reference manual about how
to use check_install_release with this new option in order to speed up
the execution of install_release.
I also added three more test cases for this functionality.
|
|
The appup instruction 'delete_module' would cause a crash during
upgrade if the module to be deleted was not loaded. The reason was
that the release_handler tried to read the version number of the old
module after the code path had changed to point to the new version of
the application. Thus, if the module had not been loaded before the
upgrade, there would no longer be any such module in the path
(delete_module indicates that the module is deleted from the new
version of the application).
This is corrected by letting the release_handler read the old version
of the module only if the module is updated - not if it is
removed. And it is always read before the code path is changed.
|
|
If a new version of an application did not include any erlang module
changes, the code path of the application was not updasted unless a
'load_object_code' instruction was added for the application. This
would be a problem if e.g. only some files in the priv dir were
changed, since calls to code:lib_dir or code:priv_dir would then point
to the old location of the application. This has been corrected - now
code:replace_path/2 will be called for all applications that are
changed (i.e. when the application's vsn is changed in the .rel file).
|
|
|