Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add v3 version of NATS JetStream protocol #1095

Merged
merged 1 commit into from
Oct 15, 2024

Conversation

stephen-totty-hpe
Copy link
Contributor

As been discussed previously, there has been a desire to implement the CloudEventSDK nats jetstream protocol using the newer jetstream package. The newer jetstream package exposes more jetstream specific functionality that should make it more flexible to use.

Much of this code is stolen from the v2 implementation and changed where necessary. It builds upon comments made in:
#1083

Under the covers, this uses a jetstream.Consumer, which can be "normal" or "ordered". This is done using consumer options WithConsumerConfig and WithOrderedConsumerConfig.

Also, the need to know the stream names upfront is not needed. Many of the internal options are available if needed, although the only required option is the ConsumerOption with the correct config.

@stephen-totty-hpe stephen-totty-hpe requested a review from a team as a code owner September 10, 2024 21:18
Copy link
Member

@embano1 embano1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the samples, please take a look at how we use a protocol in https://github.com/cloudevents/sdk-go/blob/main/samples/kafka_confluent/sender/main.go

protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options_test.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options_test.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/sender.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/message-interoperability/main.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/message-interoperability/main.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/message-interoperability/main.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/receiver/main.go Outdated Show resolved Hide resolved
@stephen-totty-hpe stephen-totty-hpe force-pushed the totty/nats-v3 branch 6 times, most recently from 16961e8 to 6f1ff3d Compare September 16, 2024 20:47
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
@stephen-totty-hpe stephen-totty-hpe force-pushed the totty/nats-v3 branch 4 times, most recently from 0e2da9c to 2cbe682 Compare September 30, 2024 19:33
@yanmxa
Copy link
Contributor

yanmxa commented Oct 8, 2024

@stephen-totty-hpe Thanks! It looks good to me. Leave it to @embano1 ~

protocol/nats_jetstream/v3/message_test.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/receiver/main.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/sender/main.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/sender.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/receiver.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/receiver.go Outdated Show resolved Hide resolved
Copy link
Member

@embano1 embano1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx for all the hard work you put into this! Some minor comments on the Options implementation (really like it) and I think we can further reduce the complexity of this code base, especially in the sender/receiver implementations. I suggested to take a look at the HTTP/Kafka (Confluent) protocol implementation for how to simplify the internal logic of this protocol.

@stephen-totty-hpe stephen-totty-hpe force-pushed the totty/nats-v3 branch 2 times, most recently from 5a16005 to 7f198df Compare October 8, 2024 18:11
protocol/nats_jetstream/v3/message_test.go Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options_test.go Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
test/integration/nats_jetstream/v3/nats_test.go Outdated Show resolved Hide resolved
test/integration/nats_jetstream/v3/nats_test.go Outdated Show resolved Hide resolved
@embano1 embano1 changed the title add v3 version of nats jetstream protocol with integration tests and samples Add v3 version of NATS JetStream protocol Oct 12, 2024
Copy link
Member

@embano1 embano1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx again for making the changes! I think this is close to merging, major feedback is now about:

  • error types, I think we should use a different approach here to keep the code simple, maintainable, and easy to use for developers, such as using this approach (with exported type though)
  • options, room for some developer experience improvements to avoid confusion how to use the protocol

protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
p.subMtx.Lock()
defer p.subMtx.Unlock()

if p.connOwned && p.conn != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still want to track owned connections? Currently the comment makes it sound that even if I specify a custom connection, conn would be closed (which would not be the case). I feel we can remove connOwned checks and handle connection closing for both situations

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The v2 version had this concept. The idea is that if a connection was passed in, we would use it and then exit without closing the connection (since it was opened before use).

With a URL, we create a connection and then close it when Close() is called:
p.conn.Close()

I am not sure if users would complain if we closed their "passed in connection".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if users would complain if we closed their "passed in connection".

Well, this is what I was referring to earlier: users are in full control (and it's actually what your doc string says for Close()). So users can decide when they underlying connection (either ours or their provided) will be closed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the comments for Close() and added a few new comments. I removed the connOwned member and only use the url member.

protocol/nats_jetstream/v3/protocol.go Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options_test.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Show resolved Hide resolved
test/integration/nats_jetstream/v3/nats_test.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
p.subMtx.Lock()
defer p.subMtx.Unlock()

if p.connOwned && p.conn != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if users would complain if we closed their "passed in connection".

Well, this is what I was referring to earlier: users are in full control (and it's actually what your doc string says for Close()). So users can decide when they underlying connection (either ours or their provided) will be closed.

protocol/nats_jetstream/v3/protocol.go Outdated Show resolved Hide resolved
}

// validationError is returned when an invalid option is given
type validationError struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: do you intentionally want to keep this internal? Fine with me to not increase the API surface for now :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left internal. I can go either way.

samples/nats_jetstream/v3/receiver/main.go Outdated Show resolved Hide resolved
samples/nats_jetstream/v3/receiver/main.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Show resolved Hide resolved
protocol/nats_jetstream/v3/options.go Outdated Show resolved Hide resolved
…samples

Signed-off-by: stephen-totty-hpe <stephen.totty@hpe.com>
Copy link
Member

@embano1 embano1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for your contribution and patience along the review! I really like the new NATS JS API you created here!

I think your other JS-related PRs can now be closed?

@embano1 embano1 merged commit 36723c5 into cloudevents:main Oct 15, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants