High processor usage

[luc1an]

Hi guys, i am in a bit of a pickle here. I have an use case with a couple of NORM instances that after a while drive the processor usage to 90-100%. I am using NORM 32 bit, within a .NET app.
The app behaves nicely for some time (up to an hour) then slowly the processor starts to work harder and harder without an apparent reason.
Is there anything that i should look for ? On another note, sometimes the ACKs don't arrive in time after i handle NORM_TX_FLUSH_COMPLETED event, so when i am getting the acking status, _normSession.GetNextAckingNode returns false.

[luc1an]

nevermind. found the culprit, it was myself... for each message sent i was starting a new NORM event handling thread. duh.

[bebopagogo]

Glad you got it worked out ... did that resolve both of these issues?

[luc1an]

Partially yes. NORM_TX_FLUSH_COMPLETED event is raised when all other nodes sent their ACKs or immediately after data is sent ? Anyways, just to be on the safe side, i put a 50 ms delay just before checking acking status for the message.

[bebopagogo]

A NORM_TX_WATERMARK_COMPLETED notification is issued when the sender ACK request process is completed (when ACKing is used). That is the appropriate time to check the acking status. If all nodes acknowledge, a "SUCCESS" status is given. Otherwise, you can iterate through the acking node list and see which receivers did and did not acknowledge.

The NORM_TX_FLUSH_COMPLETED is issued at the sender end-of-transmission and is more an indicator that no receivers are NACKing. Under high loss, it is possible for the flush to complete and with loss of all NORM_CMD(FLUSH) or NACK messages, the NORM_TX_FLUSH_COMPLETED may get issued indicating the sender is at end-of-transmission. Receivers missing data may time out and "wake up" the sender. This is where ack-based operation at the application's discretion can be used to persist for acknowledgement ... One can also set the robust factors to very high or infinite persistence (makes the protocol chattier but more robust without need for managing the ack process).

The normCast, normMsgr, and normStreamer examples (see norm/examples) provide examples of how to use the ACK request process including the necessary "bean counting" to use it for flow control (i.e., avoiding queuing too much data at the sender for ACK has completed to applicaiton's satisfaction) ... The example/normSocket.cpp extension (simplified socket-like API overlayed over the basic normApi.h API) builds this "bean counting" into state the NormSocket keeps, but the low-level API requires the application manage ack-based flow control itself.