NAME

       stompserver - Stomp protocol messaging server

SYNOPSIS

       stompserver [options]

DESCRIPTION

       Stomp   messaging  server  with  file/dbm/memory/activerecord  based  FIFO  queues,  queue
       monitoring, and basic authentication.

OPTIONS

       -C, --config=CONFIGFILE
              Configuration File (default: stompserver.conf)

       -p, --port=PORT
              Change the port (default: 61613)

       -b, --host=ADDR
              Change the host (default: localhost)

       -q, --queuetype=QUEUETYPE
              Queue type (memory|dbm|activerecord|file) (default: memory)

       -w, --working_dir=DIR
              Change the working directory (default: current directory)

       -s, --storage=DIR
              Change the storage directory (default: .stompserver, relative to working_dir)

       -d, --debug
              Turn on debug messages

       -a, --auth
              Require client authorization

       -c, --checkpoint=SECONDS
              Time between checkpointing the queues in seconds (default: 0)

       -h, --help
              Show this message

QUEUES

       Stompserver handles basic message queue  processing  using  memory,  file,  or  dbm  based
       queues.  Messages are sent and consumed in FIFO order (unless a client error happens, this
       should be corrected in the future).  Topics  are  memory-only  storage.   You  can  select
       activerecord,  file  or  dbm storage and the queues will use that, but topics will only be
       stored in memory.

       memory queues are of course the fastest ones but shouldn't be used if you want  to  ensure
       all messages are delivered.

       dbm  queues  will  use  berkeleydb  if  available,  otherwise dbm or gdbm depending on the
       platform. sdbm does not work well with marshalled data. Note that these  queues  have  not
       been tested in this release.

       For  the  file  based  storage,  each  frame is stored in a single file. The first 8 bytes
       contains the header length, the next 8 bytes contains the body length,  then  the  headers
       are stored as a marshalled object followed by the body stored as a string. This storage is
       currently inefficient because queues are stored separately from messages, which  forces  a
       double write for data safety reasons on each message stored.

       The  activerecord  based  storage expects to find a database.yml file in the configuration
       directory. It should be the most robust backend, but the slowest one.  The  database  must
       have  an  ar_messages  table  which  can  be  created  with  the  following  code (you are
       responsible to do so):

         ActiveRecord::Schema.define do
           create_table 'ar_messages' do |t|
             t.column 'stomp_id', :string, :null => false
             t.column 'frame', :text, :null => false
           end
         end

       You can read the frames with this model:

         class ArMessage < ActiveRecord::Base
           serialize :frame
         end

       The ar_message implementation will certainly change in the future.

       This is meant to be easily readable  by  a  Rails  application  (which  could  handle  the
       ar_messages table creation with a migration).

ACCESS CONTROL

       Basic  client authorization is also supported.  If the -a flag is passed to stompserver on
       startup, and a .passwd file exists in the run directory, then clients will be required  to
       provide a valid login and passcode.  See passwd.example for the password file format.

MONITORING

       Queues  can  be  monitored via the monitor queue (this will probably not be supported this
       way in  the  future  to  avoid  polluting  the  queue  namespace).  If  you  subscribe  to
       /queue/monitor,  you  will  receive  a  status  message every 5 seconds that displays each
       queue, it's size, frames enqueued, and frames dequeued. Stats are sent in the same  format
       of  stomp  headers, so they are easy to parse. Following is an example of a status message
       containing stats for 2 queues:

       Queue: /queue/client2 size: 0 dequeued: 400 enqueued: 400

       Queue: /queue/test size: 50 dequeued: 250 enqueued: 300

AUTHOR

       stompserver was written by Patrick Hurley <phurley@gmail.com> and Lionel Bouton.

       This  manual  page  was  compiled  from  the  included  documentation  by  Bryan  McLellan
       <btm@loftninjas.org>  for  the  Debian  project (and may be used by others).  The existing
       documentation is distributed under the MIT license.