@sjaak Did your question get answered? If yes, can you please accept the answer by clicking "Yes" in the line above "Did this answer the question?"? Thanks!
When publishing Persistent (Guaranteed) messages, the API will automatically resend Persistent messages if it has not received an ACK (acknowledgement) from the Solace broker within 2 seconds. (I think, pretty sure 2 seconds). You wouldn't see anything in the broker's event log. This is just a notification (not an error) from the publisher API saying that it didn't hear back from previous messages and was resending. Note that this will not cause duplicate messages on the broker... the broker and API are smart enough to de-duplicate any retransmitted messages.
Hope that helps!
@chewymints about "the application will need to maintain state..." Yes, but only in memory - it doesn't need to persist this state (as far as which message is been successfully processed) which is exactly what we're trying to achieve.
Imagine you have 1 message that's been processed, one that you've received but not sent on yet, and one that you've sent to your downstream app but don't have an ack for.
The one you've processed is fine - it's been acknowledged to the broker, so it's gone from the queue.
The one you've received but not sent on is also good - the broker will re-send it (it will also set the re-delivery flag to give you a hint why it's re-sent it)
The one you've sent on to the downstream app but don't have an ack for is more interesting. How do we know whether it's processed that message? We don't. If we can't can't afford to lose that message then we need to re-send it. That's fine, because we haven't acknowledged it to solace so on re-start the message will be re-sent (with the re-delivery flag set). Won't that mean there's a possibility of a duplicate? Yes. I'm afraid there's no way around that. The broker cannot know the state of this connection. You can get around the duplicate case by putting a sequence id in place for that connection.
I hope that helps. If you want to know more, let us know...
A non-durable endpoint will be removed from solace 60 seconds after the client that created it disconnects from the broker. The 60 seconds allows the client to reconnect before the non-durable endpoint and its contents are deleted.
To add a subscription to a non-durable queue, that can be achieved through the client application.
session.Subscribe(queue, topicA, SubscribeFlag.WaitForConfirm, null);
Where queue is your non-durable queue, topicA is the topic you would like to add to your queue, and the optional flag confirms the subscription has been applied successfully to the queue.https://docs.solace.com/API-Developer-Online-Ref-Documentation/net/html/95cb9c32-8e36-44fd-5f9f-facd8eb76502.htm
The API you are calling supports paging and the default page size is 10.
Therefore you only get 10 items.
You can specify a different count (page size) -e.g. 50, which would return all your queues - or you can use cursor and count to page through the items.
See the documentation here:https://docs.solace.com/API-Developer-Online-Ref-Documentation/swagger-ui/monitor/index.html#/queue/getMsgVpnQueues
Hi Raghu, the monitoring node participates in the leader-election voting mechanism only. It doesn't store or replicate messages.
The HA model can tolerate loss of one node, so without the voting node you can still run the two messaging nodes, and administratively fail them over to each other. Please note though that if one of those messaging nodes fails as well, the last node would stop all messaging activity until either the voting node or the peer messaging nodes returns to the HA-group.
We don't recommend message-level logging within the broker because the performance impact masks all the info you're trying to understand about performance. A good snapshot is available via 'show system health':
eventmesh> show system health
Statistics since: Jan 02 2020 13:21:06 UTC
Units Min Max Avg Curr Thresh Events
------ ------- ------- ------- ------- -------- -------
Disk Latency us 357 1864 942 809 10000000 0
Compute Latency us 900 3355305 1405 1101 500000 34
Network Latency us 0 0 0 0 2000000 0
Mate-Link Latency us 0 0 0 0 2000000 0
You can also gather smooth RTT for each connection using SEMP queries via HTTP, for example:
Hi, we don't publish a distinct broker timestamp on the messages. However, if what you're trying to do is test latency, we have done a lot of that and built latency testing capabilities into the sdkperf test suite. SDKPerf publishers put a timestamp from the local clock into each message, and the consumers extract it from the message and measure the latency delta. Note that you'd need to run the producer and consumer on the same host so they have comparable timestamps.
Is that the kind of benchmarking you're interested in doing?
Please see Andrew's response here: https://solace.community/discussion/94/spring-cloud-stream-and-solace-bindings
At this time the SCS binder will always attempt to create the queue & add the topic subscriptions.