27d1a50b35
The server reads data from a client from a go routine. When receiving messages, it checks for matching subscriptions, and if found, would send those messages from the producer's readLoop. A notion of "budget" was used to make sure the server does not spend too much time sending to clients from the producer's readLoop, however, regardless of how small the budget was, if one of the subscription's connection TCP buffer was full, a TCP write would block for as long as the defined write_deadline (which is now 10 seconds). We are removing this behavior and therefore clients (like it was the case for other type of connections) will now always notify the subscriber's writeLoop that data is ready to be sent, but the send will not occur in the producer's writeLoop. Resolves #2679 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
NATS is a simple, secure and performant communications system for digital systems, services and devices. NATS is part of the Cloud Native Computing Foundation (CNCF). NATS has over 40 client language implementations, and its server can run on-premise, in the cloud, at the edge, and even on a Raspberry Pi. NATS can secure and simplify design and operation of modern distributed systems.
Documentation
- Official documentation
- FAQ
- Watch a video overview of NATS to learn more about its origin story and design philosophy.
Contact
- Twitter: Follow us on Twitter!
- Google Groups: Where you can ask questions
- Slack: Click here to join. You can ask question to our maintainers and to the rich and active community.
Contributing
If you are interested in contributing to NATS, read about our...
Security
Security Audit
A third party security audit was performed by Cure53, you can see the full report here.
Reporting Security Vulnerabilities
If you've found a vulnerability or a potential vulnerability in the NATS server, please let us know at nats-security.
License
Unless otherwise noted, the NATS source files are distributed under the Apache Version 2.0 license found in the LICENSE file.