Sleep in Solace C API

chaudharys
chaudharys Member Posts: 25

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

  • Ragnar
    Ragnar Member, Employee Posts: 64 Solace Employee
    #2 Answer ✓

    No, not at all. When you said the last message is not not received I assume after sending the last message you destroy the session or exit, I'm suggesting you disconnect the session after the last message.

  • Ragnar
    Ragnar Member, Employee Posts: 64 Solace Employee
    #3 Answer ✓

    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.

Answers

  • Ragnar
    Ragnar Member, Employee Posts: 64 Solace Employee

    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.

  • chaudharys
    chaudharys Member Posts: 25

    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.

  • Ragnar
    Ragnar Member, Employee Posts: 64 Solace Employee
    #6 Answer ✓

    No, not at all. When you said the last message is not not received I assume after sending the last message you destroy the session or exit, I'm suggesting you disconnect the session after the last message.

  • chaudharys
    chaudharys Member Posts: 25
    edited February 2021 #7

    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?

  • chaudharys
    chaudharys Member Posts: 25

    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.

  • Ragnar
    Ragnar Member, Employee Posts: 64 Solace Employee
    #9 Answer ✓

    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.