Solace Consume

Enterprise only
Related Documentation
Made by
Kong Inc.
Supported Gateway Topologies
hybrid db-less traditional
Supported Konnect Deployments
hybrid cloud-gateways serverless
Compatible Protocols
grpc grpcs http https
Minimum Version
Kong Gateway - 3.12

This plugin allows Kong Gateway to consume messages from a Solace PubSub+ Event Broker and makes them available through HTTP endpoints. For more information, see Understanding Solace topics.

The Solace Consume plugin includes the following features:

  • Supports Basic and OAuth2 Authentication for secure communication with Solace
  • Allows dynamic configuration of Solace session properties
  • Supports custom content payloads or direct payload forwarding
  • Provides configurable acknowledgment wait time to handle guaranteed message delivery
  • SSL/TLS support for secure connections to Solace brokers

Kong also provides Solace plugins for logging and publishing messages:

Use cases and examples

See the following table for Solace Consume use cases:

Example

Description

Auto mode Run the Solace Consume plugin in auto mode, letting the plugin automatically determine the mode from the client request.
Polling mode Run the Solace Consume plugin in its default polling mode.
Server-sent events mode Stream messages using server-sent events.
WebSocket mode Stream messages over a WebSocket connection.
SSL connections Enable SSL validation.
URI capture Capture the URI of the request and use it as the message destination name.

Implementation details

The plugin supports the following modes of operation:

  • polling: Checks for messages at set intervals instead of waiting for a push notification (default)
  • auto: Determines the mode automatically from the client request
  • server-sent-events: Streams messages using server-sent events
  • websocket: Streams messages over a WebSocket connection

WebSocket mode

In websocket mode, the plugin maintains a bi-directional WebSocket connection with the client, allowing for continuous delivery of Solace messages to the client.

Here’s how it works:

  1. Establish a WebSocket connection to the Route where the Solace Consume plugin is enabled and mode is set to websocket.
  2. Kong Gateway continuously streams messages as JSON text frames.
  3. Optionally, client sends acknowledgments (client-acks) for each message or batch to enable at-least-once delivery semantics.

This approach provides real-time message flow without the limitations of HTTP polling.

 
sequenceDiagram
    participant Client
    participant Kong as Kong Gateway
    participant Broker as Message Broker

    Client->>Kong: Establish WebSocket connection
    Kong->>Broker: Connect to broker

    loop Continuous message delivery
        Broker->>Kong: Broker message
        Kong->>Client: Stream JSON text frame

        opt client-acks
            Client->>Kong: Acknowledge message/batch
        end
    end

  

Figure 1: The diagram shows the bi-directional WebSocket flow where the Solace Consume plugin is running in websocket mode, and messages are streamed as JSON text frames.

This mode provides parity with HTTP-based consumption, including support for:

  • Message keys
  • Topic filtering
  • Solace authentication and TLS
  • Auto or manual offset commits

Message delivery guarantees

When running multiple data plane nodes, there is no thread-safe behavior between nodes. In high-load scenarios, you may observe the same message being delivered multiple times across different data plane nodes.

To minimize duplicate message delivery in a multi-node setup, consider:

  • Using a single data plane node for consuming messages from specific topics
  • Implementing idempotency handling in your consuming application
  • Monitoring Consumer Group offsets across your data plane nodes

FAQs

If you encounter SSL connection issues, try the following:

  • Check if the Solace broker is properly configured for SSL connections
  • Verify that the broker’s SSL certificate is valid
  • Verify that the plugin has config.session.ssl_validate_certificate set to true
  • Ensure that the correct port is being used for SSL connections (usually port 55443)
  • Ensure that all necessary SSL parameters are configured in config.session.properties; see Consume messages over SSL for an example.

Note that the plugin doesn’t implement any retry logic, so if the connection fails, the client has to retry sending the message.

If connections to Solace fail, check the following:

  • Network connectivity between Kong Gateway and the Solace broker
  • Authentication credentials
  • VPN name and permissions
  • Review Solace broker logs for more detailed error information
  • Increase the connection timeout on the Solace side (solace_session_connect_timeout_ms), or on the Kong side (see the timeout setting for your mode)

If you experience performance issues with high concurrency, adjust the following settings in your Solace broker:

  • Adjust the session pool size (solace_session_pool)
  • Increase the ack timeout (ack_max_wait_time_ms)
  • Consider using direct messaging instead of guaranteed messaging for higher throughput

Since Kong Gateway workers are single-threaded, this plugin uses one Solace context per Kong Gateway worker with up to 4 sessions per plugin. All sessions on a plugin share the same event loop. The plugin executes non-blocking event handling to avoid delaying Kong Gateway requests.

Note: Make sure that your ulimits are high enough to handle the number of concurrent connections, and ensure that clients are using keepalive connections to avoid reaching the maximum number of file descriptors.

Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!