Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support explicit acks #121

Open
petersilva opened this issue Nov 12, 2023 · 2 comments
Open

support explicit acks #121

petersilva opened this issue Nov 12, 2023 · 2 comments
Labels
bug Something isn't working different_from_python a case where the C implementation does not behave the same as the python reference implementation.

Comments

@petersilva
Copy link
Contributor

in working on #120, I noticed that the C consumer auto_acknowledges messages in the library, in contrast to the careful control of acks in the python3.


             amqp_basic_consume(sr_c->cfg->broker->conn, 1,
                                   amqp_cstring_bytes(sr_c->cfg->queuename),
                                   //amqp_empty_bytes, // consumer_tag
                                   amqp_cstring_bytes(consumer_tag), 0, // no_local
                                   1,   // no_ack ( == auto-ack ) - if set to 1, then comment out basic_ack code above.
                                   0,   // not_exclusive
                                   amqp_empty_table);


The no_ack refers to not requiring the client to acknowledge messages. Long ago, I think there was testing of using acknowledgement, and the code is still there in comments... so I guess it never worked. Should revisit at some point.

  • note that the consumer (aka cpump) isn't used anywhere for anything at the moment, so priority of fixing it is low.

  • So this means that when messageRateMax is set to force queueing on the broker, the library will greedily read all the messages, and the broker side queue will disappear regardless of whether the application has seen it yet.

@petersilva petersilva added different_from_python a case where the C implementation does not behave the same as the python reference implementation. wishlist not a priority, but a long term wish... labels Nov 12, 2023
@petersilva petersilva added bug Something isn't working and removed wishlist not a priority, but a long term wish... labels Nov 28, 2023
@petersilva
Copy link
Contributor Author

I think this defect means all the flakey_broker flow tests can fail randomly because the C consumer will lose messages when the broker goes away (closing down the connection discards messages received by the library but not yet passed to client ... this seems to happen in some flakey_broker tests.)
))

@petersilva
Copy link
Contributor Author

sample output from tests:


test 6 FAILURE: compare contents of downloaded_by_sub_amqp and cfile differ

disabling this test in flow tests until this issue is resolved. the c consumer is not going to be resilient to failures until this is addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working different_from_python a case where the C implementation does not behave the same as the python reference implementation.
Projects
None yet
Development

No branches or pull requests

1 participant