We were using a sync.Map. This did provide a benefit with massive contention from lots of Go routines. However this is only about 2x in the crazy extremes now and with a normal map and read locks we can assist the RemoveBatch which was a cause for performance issues.
Signed-off-by: Derek Collison <derek@nats.io>
API made more consistent. Noun followed by verb.
Name arguments in request subejcts are always at the end now.
Remove enabled call, just use account info.
Getting a message directly from a stream is treated like an admin API and requires JSON request.
Deleting a message directly as well.
StreamList and ConsumerList now include details and support paging.
Streams and Consumers now contain a created field in their info.
Signed-off-by: Derek Collison <derek@nats.io>
This adds a new config option server_name that
when set will be exposed in varz, events and more
as a descriptive name for the server.
If unset though the server_name will default to the pk
Signed-off-by: R.I.Pienaar <rip@devco.net>
This would manifest for instance when server tries to send messages
to queue subscribers and a subscription is unsubsribed at the same
time.
Resolves#640
This is similar to #561 where `*` and `>` characters appear in tokens
as literals, not wilcards.
Both Insert() and Remove() were checking that the first character
was `*` or `>` and consider it a wildcard node. This is wrong. Any
token that is more than 1 character long must be treated as a literal.
Only for token of size one should we check if the character is `*`
or `>`.
Added a test case for Insert and Remove with subject like `foo.*-`
or `foo.>-`.
The issue was that a subject such as `foo.bar,*,>` would be
inserted to the cache as is, but when trying to remove from the
cache, calling matchLiteral() with the above subject in the cache
against the same subject would return false. This is because
matchLiteral would treat those characters as wildcards token.
Note that the sublist itself splits subjects on the `.` separator
and seem not bothered by such subject (would have `foo` and `bar,*,>`
tokens). Also, note that IsValidSubject() and IsValidLiteralSubject()
properly checked that the characters `*` and `>` are treated
as wildcards only if they are tokens on their own.
Resolves#558
