[rabbitmq-discuss] STOMP error messages saner (was Re: Weird Crash (91MB message over STOMP) [Reproducible])

[Tony Garnock-Jones]

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
running system.

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.

Regards,
  Tony
-- 
 [][][] 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