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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel