I am working on pipeline where JMS is sending messages to Solace queues and streaming job is consuming data from solace queues.
Here i want to plot Ingress/Egress message count on graph.
But there is huge difference between count.
here are message spool stats:
Number of ingress messages - 159479012
Number of egress messages - 222689956
How this is possible that egress count is higher?
Without knowing all the details, one scenario that I can think of which can lead to a higher egress count compared to ingress is when you have more consumers than publishers. For example, if you have a publisher publishing messages on a topic and 10 consumers with 10 queues subscribing to that topic, that message will be delivered 10 times and hence, your egress count will be 10x than the ingress count.
Additionally, if you have messages being redelivered, they would also count towards your egress.
In case, this doesn't answer your question, you might want to post this question on Solace Community (https://solace.community/).
Related
Is there any documentation on what the subsections mean under SolAdmin -> Statistics -> Client Statistics
There are two sections Total Ingress Discards / Total Egress Discards and further classification under that. I would like to understand more on the subsections under ingress/egress discards
What does Ingress and Egress messages mean with respect to solace? Is it incoming/outgoing messages from a message broker?
Any pointers to documentation on the subsections under Ingress/Egress Discards?
What does Message Spool Ingress Discard mean?
Tried searching the documentation and there was not much help. Appreciate if you can point me to the right documentation or share your knowledge here.
thanks
Yes, the ingress/egress are incoming/outgoing from the broker's perspective, that means Ingress are messages sent TO Solace from the client and egress are messages sent FROM Solace to the client.
You can find description for every discard reason on this link, on the "Description of Detailed Spooled Message Statistics" section:
Solace Message Spool Information
In general Message Spool Ingress discard means that the broker could not receive and store your message properly on the Message Spool (Guaranteed Messaging), and the reason would be one of the list that you can see in the link of Item 2.
Hope this helps.
I have a system that relies on a message bus and broker to spread messages and tasks from producers to workers.
It benefits both from being able to do true pub/sub-type communications for the messages.
However, it also needs to communicate tasks. These should be done by a worker and reported back to the broker when/if the worker is finished with the task.
Can MQTT be used to publish this task by a producer, so that it is picked up by a single worker?
In my mind the producer would publish the task with a topic "TASK_FOR_USER_A" and there are X amount of workers subscribed to that topic.
The MQTT broker would then determine that it is a task and send it selectively to one of the workers.
Can this be done or is it outside the scope of MQTT brokers such as Mosquitto?
MQTT v5 has an optional extension called Shared Subscriptions which will deliver messages to a group of subscribers in a round robin approach. So each message will only be delivered to one of the group.
Mosquitto v1.6.x has implemented MQTT v5 and the shared subscription capability.
It's not clear what you mean by 1 message at a time. Messages will be delivered as they arrive and the broker will not wait for one subscriber to finish working on a message before delivering the next message to the next subscriber in the group.
If you have low enough control over the client then you can prevent the high QOS responses to prevent the client from acknowledging the message and force the broker to only allow 1 message to be in flight at a time which would effectively throttle message delivery, but you should only do this if message processing is very quick to prevent the broker from deciding delivery has failed and attempting to deliver the message to another client in the shared group.
Normally the broker will not do any routing above and beyond that based on the topic. The as mentioned in a comment on this answer the Flespi has implemented "sticky sessions" so that messages from a specific publisher will be delivered to the same client in the shared subscription pool, but this is a custom add on and not part of the spec.
What you're looking for is a message broker for a producer/consumer scenario. MQTT is a lightweight messaging protocol which is based on pub/sub model. If you start using any MQTT broker for this, you might face issues depending upon your use case. A few issues to list:
You need ordering of the messages (consumer must get the messages in the same order the producer published those). While QoS 2 guarantees message order without having shared subscriptions, having shared subscriptions doesn't provide ordered topic guarantees.
Consumer gets the message but fails before processing it and the MQTT broker has already acknowledged the message delivery. In this case, the consumer needs to specifically handle the reprocessing of failed messages.
If you go with a single topic with multiple subscribers, you must have idempotency in your consumer.
I would suggest to go for a message broker suitable for this purpose, e.g. Kafka, RabbitMQ to name a few.
As far as I know, MQTT is not meant for this purpose. It doesn't have any internal working to distribute the tasks on workers (consumers). On the Otherhand, AMQP can be used here. One hack would be to conditionalize the workers to accept only a particular type of tasks, but that needs producers to send task type as well. In this case, you won't be able to scale as well.
It's better if you explore other protocols for this type of usecase.
I want to find the queuing time in MQTT queues such as arrival time as the event enters the queue and the ingestion time when the event is taken from the queue. Subtracting both these times can give me queueing delay. How do I find it?
There is no queuing in MQTT (apart for offline clients with high QOS subscriptions), messages are delivered to all clients subscribed to a topic as soon as it is received by the broker.
If you want to know how long it takes a broker to process a new message then it will depend on the broker, the machine it's running on, the number of clients subscribed to the topic (and at what QOS) and what the load level is. You may be able to calculate this by increasing the logging on your given broker, but this will be broker specific and any increase in logging level is likely to increase the latency as well. Your best bet would be to look at the network traffic to track inbound and outbound messages, something like wireshark would probably be best.
I have following usage pattern in an application:
The publisher sends messages to a topic with rate 5 microseconds per message (i.e. send one message every 5 micros).
Consumer subscribes to the topic and handles messages with rate 10 microseconds per message (i.e. it takes 10 micros to complete onReceive callback in JAVA API).
The consumer is interested only in the last message published to the topic, so all intermediate not handled messages can be dropped.
Is it possible to avoid the congestion in the queue of unprocessed messages on the consumer side?
I tried to use eliding with delay=0 (documentation link), however, it doesn’t help if the message already put to the internal queue in the Solace on the consumer side (I refer to com.solacesystems.jcsmp.impl.XMLMessageQueue).
Setting delay to some specific value works fine, but it doesn't scale well, because this number is dynamic and depends on the number of publishers and consumer performance.
A possible solution to this would be to create a LVQ (last value queue) which subscribes to the topic. You create a LVQ by setting the queue quota to 0 MB.
Then have your subscribing application consume messages from the LVQ.
In the appliance you should see the nearly same performance as when sending using direct messages as it will never hit the spool.
Is it possible to get the count of subscribers for a topic in Mosquitto? broker status seems to show only the total amount of subscribers.
Manageability of the broker is the "added-value". Different brokers have
different management capabilities. I know that MessageSight includes a
WEB interface and SNMP agent to query stats, but do not know this particular
feature.
Since mosquitto is open-source, you can add to its value by implementing this.
You need to subscribe to
$SYS/broker/clients/connected