🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Sleep in Solace C API
Hi
I need to send multiple messages of about 5mb each. When I send a single message without any sleep, it works fine. When I try to send 10/100/... messages without putting the publisher and subscriber to sleep for about 1 second, the last message is not received.
On printing the stats it says that the socket was filled after send, data buffered.
I want to figure out a way to send a huge quantity of messages without having to put my publisher/ subscriber to sleep for a long time, or even better not have to put them to sleep at all.
Thanks in advance!
Best Answers
-
SOLCLIENT_STATS_TX_SOCKET_FULL is a count of the number of times the API attempted to write to the socket and was unable to write all the data. This forces the API to buffer internally the rest of the message, at some point solClient_session_sendMsg() will block because the API buffer is full too. It is typically an indication of how slow your network is, but if it is exactly 100 for 100 messages I'd go out on a limb and guess you were sending very large messages, over 1MB each, possibly many MB.
It's not really a problem, if you are finding that your transmission rate is considerably lower than your available bandwidth you might tune up the socket buffer size but it is quite large already and this seldom gains much.The number of messages a client can receive on a topic is completely application dependent. There is no way for the broker to signal 'end of messages on topic' as there is theoretically no end to the messages. If you wish to communicate this from publisher to client you must do this inside the application/protocol you design, perhaps by adding a special 'end-of-messagst' message that the client will recognize.
0
Answers
-
Are you sending direct or guaranteed messages? If you are publishing guaranteed messages, you should wait for the last message acknowledgement before destroying the session. If you are publishing direct messages, you should call solClient_session_disconnect() when you are finished. This method guarantees all buffered data is flushed before closing the tcp transport. After 'disconnect' you can destroy the session as usual.
0 -
I am sending direct messages. Are you suggesting I send every message in a new session? I was sending my messages in the same session.
0 -
Thank you so much, it works!
Another thing I was wondering about was the "SOLCLIENT_STATS_TX_SOCKET_FULL" field in session stats.
I am disconnecting the session after sending my last message (100th message), all messages are sent and received accurately, but this field's value is 100. So what does it imply?0 -
Another thing, is there any property to keep the client alive and listening till all the messages on a particular topic are received.
What I am doing now is putting a while loop with a counter of the number of messages I want to receive and a sleep inside it.0 -
SOLCLIENT_STATS_TX_SOCKET_FULL is a count of the number of times the API attempted to write to the socket and was unable to write all the data. This forces the API to buffer internally the rest of the message, at some point solClient_session_sendMsg() will block because the API buffer is full too. It is typically an indication of how slow your network is, but if it is exactly 100 for 100 messages I'd go out on a limb and guess you were sending very large messages, over 1MB each, possibly many MB.
It's not really a problem, if you are finding that your transmission rate is considerably lower than your available bandwidth you might tune up the socket buffer size but it is quite large already and this seldom gains much.The number of messages a client can receive on a topic is completely application dependent. There is no way for the broker to signal 'end of messages on topic' as there is theoretically no end to the messages. If you wish to communicate this from publisher to client you must do this inside the application/protocol you design, perhaps by adding a special 'end-of-messagst' message that the client will recognize.
0
