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

Blocking calls in kafta tests #129

Open
Arooba-git opened this issue Jul 24, 2023 · 4 comments
Open

Blocking calls in kafta tests #129

Arooba-git opened this issue Jul 24, 2023 · 4 comments

Comments

@Arooba-git
Copy link
Contributor

Arooba-git commented Jul 24, 2023

HI! 🙂

Thank you for this project.

As we were going through the source , we found these blocking calls in AbstractIT class of the Kafka.it tests:
vsb2-blocking

This method is called in another method where a timed await is called immediately after calling the above (sendToTopic) method:
Screen Shot 2023-07-24 at 6 19 48 PM

Which got us thinking , if we are waiting anyway, then why use .block operator and block the event loop.. Would it not be just fine to subscribe? 🤔 We tried the test cases with subscribe() and they still passed..

We also evaluated the performance difference when using block vs subscribe (in terms of thread count and heap usage), and the subscribe version seem to outperform in both.

I know this is just test code but considering many users are and will be using it for their project, we might as well set good example by avoiding blocking calls wherever possible in a reactive chain/event loop.

We created a PR with the change in case you deem it fit: #130 :)

@cescoffier
Copy link

I don't think the test runs on the event loop, so blocking is acceptable.

That being said, in this case, block() may not be necessary. In this case, it waits for the acknowledgment from the broker. However, if the send fails, it would throw an exception, giving more information about the problem than just a timeout in the await call.

Another aspect to consider is that, anyway, the send method may block (batching on the client side), even if used without block().

@Arooba-git
Copy link
Contributor Author

@cescoffier Thank you for the detailed response!

I don't think the test runs on the event loop, so blocking is acceptable.

Hmmm tbh I'm not an expert on reactive programming, but this .block() in test was also detected by BlockHound, so we guessed it implies some main thread (in this case event loop) is indeed being blocked 🤔

However, if the send fails, it would throw an exception, giving more information about the problem than just a timeout in the await call.

Makes sense :). though is there not a more reactive approach of handling errors in such scenarios? 🤔

@cescoffier
Copy link

Do you have the name of the thread running the test?

Anyway, if that test must not be blocked, I don't believe sending like this should be allowed (probably not detected, but it can block).

@Arooba-git
Copy link
Contributor Author

Do you have the name of the thread running the test?

hm, I would have to rerun it again with the profiler, let me get back to you once I have it. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants