[rabbitmq-discuss] STOMP error messages saner (was Re: Weird Crash (91MB message over STOMP) [Reproducible])
tonyg at lshift.net
Thu Aug 20 11:51:58 BST 2009
Darien Kindlund wrote:
> One quick question: Is there any way to swap different versions of
> compiled STOMP adapters without having to restart RabbitMQ?
Yessssss.... maybe. Um. Erlang lets you reload modules. We haven't
provided an interface for doing so, though. Um. You could try replacing
the .beam file and then using
erl_call -a 'code load_file [stomp_frame]' -n rabbit
erl_call -a 'code load_file [rabbit_stomp]' -n rabbit
With the specific changes you want to test, that's unlikely to work,
because the state records have changed shape. Existing connections will
probably crash (but the broker should stay up, and new connections
should be fine).
In situations where only the code changes, though, or where the OTP
structured state upgrade mechanism are in place, then using
code:load_file/1 should work fine to upgrade bits and pieces in a
Note that there are plenty of caveats about the precise way this works.
>From the code(3erl) manpage:
CURRENT AND OLD CODE
The code of a module can exists in two variants in a
system: current code and old code. When a module is
loaded into the system for the first time, the code of
the module becomes ’current’ and the global export ta‐
ble is updated with references to all functions
exported from the module.
If then a new instance of the module is loaded (per‐
haps because of the correction of an error), then the
code of the previous instance becomes ’old’, and all
export entries referring to the previous instance are
removed. After that the new instance is loaded as if
it was loaded for the first time, as described above,
and becomes ’current’.
Both old and current code for a module are valid, and
may even be evaluated concurrently. The difference is
that exported functions in old code are unavailable.
Hence there is no way to make a global call to an
exported function in old code, but old code may still
be evaluated because of processes lingering in it.
If a third instance of the module is loaded, the code
server will remove (purge) the old code and any pro‐
cesses lingering in it will be terminated. Then the
third instance becomes ’current’ and the previously
current code becomes ’old’.
For more information about old and current code, and
how to make a process switch from old to current code,
refer to Erlang Reference Manual.
 Tony Garnock-Jones | Mob: +44 (0)7905 974 211
 LShift Ltd | Tel: +44 (0)20 7729 7060
  http://www.lshift.net/ | Email: tonyg at lshift.net
More information about the rabbitmq-discuss