Made changes to processSub() to accept subscription properties,
including the icb callback so that it is set prior to add the
subscription to the account's sublist, which prevent races.
Fixed some other racy conditions, notably in addServiceImportSub()
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Previously unlimited accounts - ones who inherit server values - would
be unable to publish any messags at all
Signed-off-by: R.I.Pienaar <rip@devco.net>
API still only turned on for account info in disabled accounts. Issues with advisories. Plan is still to have all endpoints on in all accounts.
Stream list and Consumer list return names only, page limit increased to 1024.
Stream, Consumer and Template names limited to 256 for now.
Subject API for stream messages, delete and get, not have STREAM.MSG.
Subject API for Durable is now CONSUMER.DURABLE.
Subject API for Templates now STREAM.TEMPLATE.
All subject APIs for list reverted back, so STREAM.LIST, CONSUMER.LIST etc.
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>
Removed usage of +OK and -ERR. All responses are valid json objects now and optionally can include an ApiError which will have Code and Description.
Signed-off-by: Derek Collison <derek@nats.io>
I anticipate it would be desirable to allow a microservice running
in an account to create only the stream it needs when it starts up
if there is no stream but no others, so a ACL would be written to
allow that.
Thus adding the T pattern to stream create too.
This is a proposal to add schema, timestamps and unique ids to
events. For now just JS ones but I propose to do these for all
events the server sends that might be end user consumed.
These exist to help the user identify a message even if it was
sent to a 3rd party system, the schema will be translatable to
a well known url like https://nats.io/schames/jetstream/event/v1/obs_ack.json
or to another wll known identifier like a NATS subject name
We'd publish JSON schema documents at these well known locations
describing each key and so forth
