| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
since the queue was being set in an async task and we were then calling send asserting that the queue was set, we could have triggered a panic.
didn't run into it but seemed likely to cause issues in the future.
also compute the buffer size for operators at comptime.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
clean up some tests
|
| |
|
|
|
| |
not sure why, seems like i'm using the right allocators everywhere?
need to take another pass at this later.
|
| | |
|
| | |
|
| |
|
|
|
| |
simplify code
clean up dead code
|
| |
|
|
|
| |
dosen't flush every message, pulls batches from the queue to send, and flushes at the end of each batch.
batches are a min of 1 message, but may be more.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
way faster than before even??
coder@08714a4174bb:~$ nats bench pub foo -s localhost:4223
05:12:23 Starting Core NATS publisher benchmark [clients=1, msg-size=128 B, msgs=100,000, multi-subject=false, multi-subject-max=100,000, sleep=0s, subject=foo]
05:12:23 [1] Starting Core NATS publisher, publishing 100,000 messages
Finished 0s [====================================================================================] 100%
NATS Core NATS publisher stats: 574,666 msgs/sec ~ 70 MiB/sec ~ 1.74us
So cool.
src/server/client.zig JJ: M src/server/main.zig JJ: JJ: Lines starting with "JJ:" (like this one) will be
removed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Break up creating and starting the client process.
I think this should simplify storing the std.Io.Queue on the stack.
Before I was storing it on the heap because it was hard to make it point to the same location if I was initializing the client on the stack.
|
| | |
|
| |
|
|
| |
starting to use errors instead of unreachable for stream parsing
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
the message isn't crossing container boundaries, but it works in the
test!
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|