| Commit message (Collapse) | Author | Age |
| | |
|
| |
|
|
|
|
|
|
|
| |
coder@08714a4174bb:~$ nats bench sub foo -s localhost:4223
03:28:04 Starting Core NATS subscriber benchmark [clients=1, msg-size=128 B, msgs=100,000, multi-subject=false, subject=foo]
03:28:04 [1] Starting Core NATS subscriber, expecting 100,000 messages
Finished 6s [====================================================================================] 100%
NATS Core NATS subscriber stats: 14,691 msgs/sec ~ 1.8 MiB/sec ~ 68.06us
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Assert implies panic, expect implies error
|
| |
|
|
|
| |
Was accidentally consuming one more byte than I was expecting when reaching the end of the second term.
This was causing the parser to work properly in the case that a queue group was specified, but failing and consuming the next message (usually a PING) as the SID.
|
| |
|
|
|
| |
This lets me dev cycle faster
Shouldn't have to do this though, should be cleaning up properly
|
| | |
|
| | |
|
| |
|
|
| |
starting to use errors instead of unreachable for stream parsing
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
the message isn't crossing container boundaries, but it works in the
test!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is compatible with the latest 0.16.0 nightly build.
It is also a bit less magic than clap.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|