As part of my own learning when I joined Solace few months back, I collected all references available and utilized them as a ready reckoner - code, lab, tutorial and reading.
Sharing it, hoping that new members could benefit.
Solace - GitHub
Solace - Products
Solace - Specific references
Solace CLI Reference
Solace Error/Message Details
SEMP (Solace Element Management Protocol) v2
Solace Event Portal REST API
Solace Event Portal Open API - Swagger Spec
Solace Quick Starts - References
Solace PubSub+ Cache
Solace Geneos Agent
Solace Versions - Release Notes (Compatibility)
Solace - Product Lifecycle Policy
Solace - Best Practices
Solace - Feature Index
Solace - General Reference
Solace - Internal Portals
Solace - Social Media Portals
Solace - Public Forums
Folks, I there are more references that can be added to the list - please update in the comments. Let us make the onboarding journey of new members as easy and enjoyable as possible
Queue as a noun, represents a list of objects, commands, etc., stored in a retrievable, definite order in the order of insertion.
Queue as a verb, represents an operation to (re)arrange items from the set of operations such as dequeue, browse, replicate, empty, etc available on a queue.
Solace Queues are created and managed by configurations that determine lifecycle characteristics and operational controls. These queue settings determine the behavior of the queue at run-time.
Solace Queues at design-time
The Part (1 of 2) can be found here.
Design Time configurations (Part 2)
Following are some of the configurations that control the runtime functioning of the queue. Solace queues offer numerous nuanced controls that can empower the designers to build systems suited and performant for their specific needs.
6. Message Priority
Enable or disable the respecting of message priority. When enabled, messages contained in the Queue are delivered in priority order, from 9 (highest) to 0 (lowest). MQTT queues do not support enabling message priority.
7. Message Expiry
Message expiry is a timer that dictates the lifespan of the message. The message will persist on an endpoint until that timer expires. Without this timer, a message will persist on a Solace endpoint indefinitely, or until it is consumed by an application or deleted by an administrator.
a) Respect TTL
Enable or disable the respecting of the time-to-live (TTL) for messages in the Queue. When enabled, expired messages are discarded or moved to the DMQ.
b) Maximum TTL (secs)
The maximum time in seconds a message can stay in the Queue when Respect TTL is enabled. A message expires when the lesser of the sender assigned TTL in the message and the Maximum TTL configured for the Queue, is exceeded. A value of 0 disables expiry.
Enable or disable message redelivery. When enabled, the number of redelivery attempts is controlled by maxRedeliveryCount. When disabled, the message will never be delivered from the queue more than once.
d) Maximum Redelivery count
The maximum number of message redelivery attempts that will occur prior to the message being discarded or moved to the DMQ.
8. Dead Message Queue
Messages are removed from a durable endpoint's message spool and discarded when the number of redelivery attempts for a message exceeds the Max Redelivery value for the original destination endpoint; or a message’s TTL value has been exceeded, and the endpoint is configured to respect message TTL expiry times.
If you want the discarded messages to be captured, create a queue and assign that queue as dead message queue (DMQ) assigned to the endpoint.
a) DMQ Name
The name of the Dead Message Queue (DMQ) used by the Queue. Note that the queue must be created and exist at the time of client activity.
9. Congestion Control
a) Reject Messages to Sender on Discard
Determines when to return negative acknowledgments (NACKs) to sending clients on message discards. Note that NACKs cause the message to not be delivered to any destination and Transacted Session commits to fail.
Always: Always return a negative acknowledgment (NACK) to the sending client on message discard.
When Queue Enabled: Only return a negative acknowledgment (NACK) to the sending client on message discard when the Queue is enabled.
Never: Never return a negative acknowledgment (NACK) to the sending client on message discard.
b) Reject Low Priority Messages
Enable or disable the checking of low priority messages against the Reject Low Priority Messages Limit. When enabled, the Reject Messages to Sender on Discard option must have a value of "When Queue Enabled" or "Always" so that session events are sent to the sending clients whenever messages are not enqueued and are discarded. Before enabling it is recommended that the Reject Low Priority Messages Limit have a non-zero value to avoid inadvertently discarding all low priority messages.
c) Reject Low Priority Messages Limit
The number of messages of any priority in the Queue above which low priority messages are not admitted but higher priority messages are allowed. To avoid inadvertently discarding all low priority messages, before enabling Reject Low Priority Messages it is recommended that you change the default value of 0 to a value more appropriate for your network.
d) Priority Messages Limit Alert Thresholds
The thresholds for the maximum allowed number of any priority messages queued in the Queue alert, relative to Reject Low Priority Messages Limit.
10. Disaster Recovery
a) Consumer Acknowledgement Propagation
Enable or disable the propagation of consumer acknowledgments (ACKs) received on the active replication Message VPN to the standby replication Message VPN.
Is there any book reelased on Solace (Pubsub+) ? Or any online Tutorals for Architect and Developers ?
For those of you who are asking, “Can I span a DMR mesh across nodes running different PubSub+ Event Broker versions?", the answer is Yes! You just need to make sure that all nodes in the mesh are running 9.6 or later.
So you want to build a multi-Cloud event mesh that spans three continents and share events between them? This video walks you through the beta Mesh Manager feature of PubSub+ Cloud and shows you how you can complete that task using Mesh Manager in just a couple of mouse clicks.
Watch the 3-minute video at https://video.solace.com/watch/NAPhdRreKnMzF6FANrqeiU.
EDA is one of the many topics I am passionate about and I am regularly involved with topics and conversations about it in the community. Just like any other domain, there are some claims and myths in EDA that people exchange every now and then. I wanted to start this conversation here to hear from you all: Have you heard any myths in EDA? Is there a claim about event-driven architectures that people confuse for a myth but its actually a fact? Let start a discussion here!
I started a series of EDA Myth Busting. Here are some of my top favourite claims
- "EDA is for high throughput use cases only" --> MYTH!
"Event Streams are for internal use only. I shouldn’t share them outside of my department or organization"
"Exposing APIs on our legacy app or monolith makes it eventdriven" --> MYTH! Courtesy of Thorsten Heller on Twitter
Any other input from you all on this?
The recent v9.9 release of the PubSub+ Event Broker and the API releases that came with it now support the ability to trigger replay from a specific message id. I just wanted to share some info on how to use it with some of the different APIs!
Note that the Message ID is in available in the header of each Solace Message and each Solace SMF API allows you to easily retrieve it.
Using CCSMP for Replay from Message ID
const string &replayMsgId = "rmid1:0117b-75462900ca8-00000000-00135082"; flowProps[propIndex++] = strdup(SOLCLIENT_FLOW_PROP_REPLAY_START_LOCATION); flowProps[propIndex++] = strdup(replayMsgId.c_str()); csmpRc = solClient_session_createFlow( (char **)flowProps, session_mp, &opaqueFlow_p, &flowFuncInfo, sizeof(flowFuncInfo));
Using JCSMP for Replay from Message ID:
String replayMsgId = "rmid1:0117b-75462900ca8-00000000-00135082"; ReplayStartLocation loc = JCSMPFactory.onlyInstance().createReplicationGroupMessageId(replayMsgId); consFlowProps.setReplayStartLocation(loc); consumer = _jSession.createFlow(myConsumer, consFlowProps, null, myConsumer);
var replayMsgId = "rmid1:0117b-75462900ca8-00000000-00135082"; messageConsumerProperties.replayStartLocation = solace.SolclientFactory.createReplicationGroupMessageId(replayMsgId); consumer = this.m_session.createMessageConsumer(messageConsumerProperties);
Using .NET for Replay from Message ID
Note: One important thing about .NET is the ReplayStartLocation property in FlowProperties has been deprecated so it needs to use ReplayStartLocationEx (All the other replay start locations should use it as well in the future)
FlowProperties fp = new FlowProperties(); String replayMsgId = "rmid1:0117b-75462900ca8-00000000-00135082"; IReplicationGroupMessageId rpStart = ContextFactory.Instance.CreateReplicationGroupMessageId(replayMsgId); fp.ReplayStartLocationEx = rpStart; flowHandle = m_session.CreateFlow(fp, bindEndp
Using JavaRTO for Replay from Message ID:
Map<String, String> flowPropsMap = new HashMap<String, String>(_flowProperties); String replayMsgId = "rmid1:0117b-75462900ca8-00000000-00135082"; flowPropsMap.put(FlowHandle.PROPERTIES.REPLAY_START_LOCATION, replayMsgId ); EventsAdapter myConsumer = new EventsAdapter(this, queue, flowProps, null, null, transactedSession, wantMsgPriorityOrderChecking);
Hope this thread comes in handy for folks trying to use this feature in the future
Go ahead and give it a like if it does and we'll continue to try to share content like this for future features.