stompserver - Online in the Cloud

PROGRAM:

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

Use stompserver online using onworks.net services