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 optional DeliverTo field to ConsumerGetNextRequest JS API #1929

Closed
wants to merge 1 commit into from

Conversation

wallyqs
Copy link
Member

@wallyqs wallyqs commented Feb 22, 2021

This adds a DeliverTo which can be used to signal the server where the next message should be delivered after sending the next message request. This way when a client makes a request to pull messages, it can receive the response from a different response handler than the subscription that is processing the messages.

Signed-off-by: Waldemar Quevedo wally@synadia.com

  • Tests added
  • Branch rebased on top of current master (git pull --rebase origin master)
  • Changes squashed to a single commit (described here)
  • Build is green in Travis CI
  • You have certified that the contribution is your original work and that you license the work to the project under the Apache 2 license

/cc @nats-io/core

@wallyqs wallyqs force-pushed the js-pull-sync-deliver-to branch 2 times, most recently from bd7bd83 to aeadb6c Compare February 25, 2021 23:27
@wallyqs wallyqs marked this pull request as draft February 26, 2021 01:14
@wallyqs
Copy link
Member Author

wallyqs commented Feb 26, 2021

As is this wouldn't work when the pull request is done across accounts, it needs to be aware of the remapped inbox:

[83750] 2021/02/25 17:13:39.893837 [TRC] [::1]:57987 - cid:19 - "v1.11.0:go" - <<- [PUB $JS.API.CONSUMER.MSG.NEXT.foo.p1 _INBOX.FdjTGbgmxBWWMDXJTDGiA6.jejKsJcA 56]
[83750] 2021/02/25 17:13:39.893852 [TRC] [::1]:57987 - cid:19 - "v1.11.0:go" - <<- MSG_PAYLOAD: ["{\"batch\":1,\"deliver_to\":\"_INBOX.FdjTGbgmxBWWMDXJTDGiCm\"}"]
[83750] 2021/02/25 17:13:39.893926 [TRC] [::1]:57987 - cid:19 - "v1.11.0:go" - ->> [MSG _R_.Jqf851.3tLjgP 1 0]


if shouldRespond {
// Empty message meaning that there were no errors.
pmsg := &jsPubMsg{reply, reply, _EMPTY_, nil, nil, nil, 0}
Copy link
Member Author

Choose a reason for hiding this comment

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

In case the sub.Pull() is done from another account, then this would not deliver the response.

Copy link
Member

Choose a reason for hiding this comment

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

This should work ok once I push the current branch. Sync with that should work fine.

Copy link
Member

Choose a reason for hiding this comment

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

This should not be needed. Let's chat in am.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just tried with latest and seems that for the approach in this PR, it still needs to transform the reply inbox. An alternative that I was thinking to make the sub.Poll() synchronous is to handle as an old style request on the client side: https://github.com/nats-io/nats.go/blob/118341e3023b7bf5bf01b3f332b98fc52e2c22b1/js.go#L913-L980

This adds a DeliverTo which can be used to signal the server where the
next message should be delivered after sending the next message
request.  This way when a client makes a request to pull messages, it
can receive the response from a different response handler than the
subscription that is processing the messages.

Signed-off-by: Waldemar Quevedo <wally@synadia.com>
@wallyqs
Copy link
Member Author

wallyqs commented Feb 26, 2021

Closing since taking a different approach.

@wallyqs wallyqs closed this Feb 26, 2021
@wallyqs wallyqs deleted the js-pull-sync-deliver-to branch March 14, 2021 20:27
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.

None yet

2 participants