- Reference manual
- SWI-Prolog Python interface
- SWI-Prolog Semantic Web Library 3.0
- mqi -- Python and Other Programming Languge Integration for SWI Prolog
- Constraint Query Language A high level interface to SQL databases
- SWI-Prolog binding to GNU readline
- SWI-Prolog ODBC Interface
- SWI-Prolog binding to libarchive
- Transparent Inter-Process Communications (TIPC) libraries
- JPL: A bidirectional Prolog/Java interface
- Pengines: Web Logic Programming Made Easy
- Redis -- a SWI-Prolog client for redis
- SWI-Prolog SSL Interface
- Google's Protocol Buffers Library
- SWI-Prolog Natural Language Processing Primitives
- Prolog Unit Tests
- SWI-Prolog Unicode library
- SWI-Prolog YAML library
- SWI-Prolog HTTP support
- SWI-Prolog Regular Expression library
- Managing external tables for SWI-Prolog
- A C++ interface to SWI-Prolog
- SWI-Prolog SGML/XML parser
- sweep: SWI-Prolog Embedded in Emacs
- SWI-Prolog binding to zlib
- Paxos -- a SWI-Prolog replicating key-value store
- SWI-Prolog Source Documentation Version 2
- SWI-Prolog C-library
- SWI-Prolog binding to BSD libedit
- STOMP -- a SWI-Prolog STOMP client
- SWI-Prolog RDF parser
SWI-Prolog Solutions b.v.
- Hongxin Liang and Jan Wielemaker
- See also
- - http://stomp.github.io/index.html
- To be done
- TSL support
This module provides a STOMP (Simple (or Streaming) Text Orientated Messaging Protocol) client. This client is based on work by Hongxin Liang. The current version is a major rewrite, both changing the API and the low-level STOMP frame (de)serialization.
The predicate stomp_connection/5 is used to register a connection. The connection is established by stomp_connect/1, which is lazily called from any of the predicates that send a STOMP frame. After establishing the connection two threads are created. One receives STOMP frames and the other manages and watches the heart beat.
Upon receiving a frame the callback registered with stomp_connection/5 is called in the context of the receiving thread. More demanding applications may decide to send incomming frames to a SWI-Prolog message queue and have one or more worker threads processing the input. Alternatively, frames may be inspected by the receiving thread and either processed immediately or be dispatched to either new or running threads. The best scenario depends on the message rate, processing time and concurrency of the Prolog application.
All message sending predicates of this library are thread safe. If two threads send a frame to the same connection the library ensures that both frames are properly serialized.
By default this library tries to establish the connection and the
user gets notified by means of a
disconnected pseudo frame
that the connection is lost. Using the Options argument of stomp_connection/6
the system can be configured to try and keep connecting if the server is
not available and reconnect if the connection is lost. See the
- [det]stomp_connection(+Address, +Host, +Headers, :Callback, -Connection)
- [det]stomp_connection(+Address, +Host, +Headers, :Callback, -Connection, +Options)
- Create a connection reference. The connection is not set up yet by this
predicate. Callback is called on any received frame except
heart beat frames as below.
call(Callback, Command, Connection, Header, Body)
Where command is one of the commands below. Header is a dict holding the STOMP frame header, where all values are strings except for the
'content-length'key value which is passed as an integer.
Body is a string or, if the data is of the type
application/json, a dict.
- A connection was established. Connection and Header are valid.
- The connection was lost. Only Connection is valid.
- A message arrived. All three arguments are valid. Body is a dict if the
content-typeof the message is
application/jsonand a string otherwise.
- A heartbeat was received. Only Connection is valid. This callback is also called for each newline that follows a frame. These newlines can be a heartbeat, but can also be additional newlines that follow a frame.
- No heartbeat was received. Only Connection is valid.
- An error happened. All three arguments are valid and handled as
- Try to reestablish the connection to the server if the connection is
lost. Default is
- Maximum time to try and reestablish a connection. The default is
- Options passed to json_read_dict/3
application/jsoncontent to Prolog. Default is
Address is a valid address for tcp_connect/3. Normally a term Host:Port, e.g.,
Host is a path denoting the STOMP host. Often just
Headers is a dict with STOMP headers used for the
Connection is an opaque ground term that identifies the connection.
- [nondet]stomp_connection_property(?Connection, ?Property)
- True when Property, is a property of Connection.
Defined properties are:
- All the above properties result from the stomp_connection/6 registration.
- These describe an active STOMP connection.
- Destroy a connection. If it is active, first use stomp_teardown/1 to disconnect.
- [det]stomp_setup(+Connection, +Options)
- Set up the actual socket connection and start receiving thread. This is
a no-op if the connection has already been created. The Options
processed are below. Other options are passed to tcp_connect/3.
- If tcp_connect/3 fails, retry until the
timeout is reached. If Seconds is
infinite, keep retrying forever.
- Tear down the socket connection, stop receiving thread and heartbeat thread (if applicable). The registration of the connection as created by stomp_connection/5 is preserved and the connection may be reconnected using stomp_connect/1.
- Teardown the connection and try to reconnect.
- [det]stomp_connect(+Connection, +Options)
- Setup the connection. First ensures a socket connection and if this is
new send a
CONNECTframe. Protocol version and heartbeat negotiation will be handled.
STOMPframe is not used for backward compatibility.
This predicate waits for the connection handshake to have completed. Currently it waits for a maximum of 10 seconds after establishing the socket for the server reply.
Calling this on an established connection has no effect.
stomp_error(connect, Connection, Detail)if no connection could be established.
- See also
- [det]stomp_send(+Connection, +Destination, +Headers, +Body)
- Send a
content-typeis not provided,
text/plainwill be used.
content-lengthwill be filled in automatically.
- [det]stomp_send_json(+Connection, +Destination, +Headers, +JSON)
- Send a
JSONcan be either a JSON term or a dict.
content-typeis filled in automatically as
content-lengthwill be filled in automatically as well.
- [det]stomp_subscribe(+Connection, +Destination, +Id, +Headers)
- Send a
- [det]stomp_unsubscribe(+Connection, +Id)
- Send an
- [det]stomp_ack(+Connection, +MessageId, +Headers)
- Send an
ACKframe. See stomp_ack/2 for simply passing the header received with the message we acknowledge.
- [det]stomp_nack(+Connection, +MessageId, +Headers)
- Send a
NACKframe. See stomp_nack/2 for simply passing the header received with the message we acknowledge.
- [det]stomp_ack(+Connection, +MsgHeader)
- [det]stomp_nack(+Connection, +MsgHeader)
- Reply with an ACK or NACK based on the received message header. On a
STOMP 1.1 request we get an
ackfield in the header and reply with an
id. For STOMP 1.2 we reply with the
subscriptionthat we received with the message.
- [det]stomp_begin(+Connection, +Transaction)
- Send a
BEGINframe. @see http://stomp.github.io/stomp-specification-1.2.html\#BEGIN
- [det]stomp_commit(+Connection, +Transaction)
- Send a
- [det]stomp_abort(+Connection, +Transaction)
- Send a
- [semidet]stomp_transaction(+Connection, :Goal)
- Run Goal as once/1, tagging all
SENDmessages inside the transaction with the transaction id. If Goal fails or raises an exception the transaction is aborted. Failure or exceptions cause the transaction to be aborted using stomp_abort/2, after which the result is forwarded.
- [det]stomp_disconnect(+Connection, +Headers)
- Send a
DISCONNECTframe. If the connection has the
reconnectproperty set to
true, this will be reset to
disconnectedto avoid reconnecting. A subsequent stomp_connect/2 resets the reconnect status.