On Tue, Dec 14, 2010 at 11:05:05AM +0000, Dietmar Maurer wrote:
If during this you start having trouble processing them all - then you return -1 from your process_message function. This will cause the IPC server to stop doing bulk processing and go back to the poll loop.
So it stops ' bulk processing', but normal processing continues?
Yes.
If you want to block normal incomming requests use:
qb_ipcs_request_rate_limit(s, QB_IPCS_RATE_OFF);
then later to turn it on again
qb_ipcs_request_rate_limit(s, QB_IPCS_RATE_NORMAL);
Or to shutdown the connection.
qb_ipcs_disconnect(c);
OK
when I run this i get tons of: qb_ipcc_recv: -11 qb_ipcc_recv: -11 qb_ipcc_recv: -11
At which you can handle backing off or disconnecting.
Ah, so qb_ipcc_recv() works.
But what is with qb_ipcc_sendv_recv()? It simply does and endless loop.
I am not crazy about this function, it was added mainly as a convience function for corosync (coroipcc_msg_send_reply_receive() behaves in a simerlar way as far as I can see). I prefer to use the send and recv functions seperatly as you can handle these kind of conditions better.
I think it would make sense to have a timeout on the recv functions. It will just need a bigger patch in corosync (for the API change).
Regards -Angus
repeat_recv: res = qb_ipcc_recv(c, res_msg, res_len); if (res == -EAGAIN) { goto repeat_recv;
-EAGAIN is usually used for correctable errors. A timeout is something different.
- Dietmar
quarterback-devel mailing list quarterback-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/quarterback-devel