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.

Sign up for GitHub

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

Jump to bottom

1 second delay on .net framework when receiving messages #78

Closed
zlepper opened this issue Apr 26, 2021 · 3 comments · Fixed by #79
Closed

1 second delay on .net framework when receiving messages #78

zlepper opened this issue Apr 26, 2021 · 3 comments · Fixed by #79

Comments

@zlepper
Copy link
Contributor

zlepper commented Apr 26, 2021

There is something funky going on on .net framework when receiving messages, when there is nothing buffered in the queue. From my testing there seems to be about 1 second delay between the message being send from service A, to it being received in service B, provided service B is a .net framework application. I have not observed the same behavior on .net core.

Looking at the code in this library, the transport has a timeout of 2 seconds when receiving messages, which i what i suspect .net framework always waits, worst case scenario. I suspect it's the SharedQueue that doesn't notify the callling code that a new message has been received, causing the delay.

I have not done any carefull measures, but looking at the traces emitted from Rebus.OpenTelemetry, it certainly seems to be the case. I have tested everything on the same host, including Rabbit, so it really shouldn't be a network issue.
@mookid8000
Copy link
Member

The SharedQueue implementation found in the codebase of Rebus.RabbitMq comes from an older version of RabbitMq.Client, so it's basically something that was ported forward when it was removed from the official driver NuGet package.

I can see it's using DateTime.Now in its implementation of the timeout..... I would not believe that that could cause the behavior you're experiencing, but just for kicks I've changed it to use a Stopwatch instead. I've released it as Rebus.RabbitMq 7.3.1-b3 – could you try it and see if that makes a difference?

@zlepper
Copy link
Contributor Author

zlepper commented Apr 27, 2021 •
edited
Loading

That seems to have fixed it!

Or maybe not... It's quite difficult to see and measure..

@mookid8000
Copy link
Member

Yeah ok 😁 I'd be happy to hear about your results once you've had a chance to observe it for a while.

@zlepper zlepper mentioned this issue Apr 27, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

More push based operations Digizuite/Rebus.RabbitMq
2 participants
@mookid8000 @zlepper