-
Notifications
You must be signed in to change notification settings - Fork 177
Publishing plus immediate flush #1211
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
Conversation
* Flushes the underlying connection buffer the next chance it gets if the connection is valid. | ||
* @throws IOException not applicable even though it's part of the signature due to implementation change | ||
* Immediately flushes the underlying connection buffer if the connection is valid. | ||
* @throws IOException the connection flush fails |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*if the connection flush fails
@@ -269,38 +269,41 @@ NatsMessage accumulate(long maxSize, long maxMessages, Duration timeout) | |||
return null; | |||
} | |||
|
|||
NatsMessage msg = this.poll(timeout); | |||
NatsPublishableMessage msg = (NatsPublishableMessage)this.poll(timeout); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this cast safe, poll(..)
returns NatsMessage
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so because of single reader mode but I will review
* Flushes the underlying connection buffer the next chance it gets if the connection is valid. | ||
* @throws IOException not applicable even though it's part of the signature due to implementation change | ||
* Immediately flushes the underlying connection buffer if the connection is valid. | ||
* @throws IOException if the connection flush fails |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This simply reverts the comments back to the original, correct comment.
When a "request" was made, there were two pieces of code
called in succession
The intention was that on a request, we want to get the publish part of the request out over the socket quickly. But because operation 1 simply queues the message, the flush likely happens before the message even got moved to the socket
So instead of the 2 step process that was did not do what was intended, I added internally the ability to say "flush right after this publish"
It sets a flag on the message in the queue and when processing that message for the queue, when I see the flag, I flush
So instead of the 2 steps, I now do a publish and set the flag on that message.
This only affects "requests" which is what was originally intended. This does not affect publishing.