Support setting a custom inbox prefix via nats.Options

[simonfxr]

Description

This PR makes it possible to configure a custom inbox prefix.

Comments and critique welcome :-)

Use Case:

We @pascomnet are using a unique service identifier as part of every subject
including inboxes, without custom inbox prefix suppport we can't use the go
clients built in facilities for Requests, while e.g. the java client supports
this out of the box.

Proposed Change:

It can be done in a fully backwards compatible way (see pull request)

• Add a new InboxPrefix field to nats.Options
• Add a new function Conn.NewInbox.
• Deprecate the free function NewInbox() and direct people to use Conn.NewInbox function instead.

Who Benefits From The Change(s)?

Everyone who wants to use this feature :-)

Alternative Approaches

Do not use the builtin request/inbox client features, without reimplementing the
relevant nats.go parts this is a lot less efficient, a naive approach requires a
new subscription per request. In effect this is similar to old style requests.

Benchmarks

Here is my benchmark environment:

❯ cat /proc/cpuinfo | grep -i 'model name' | head -1
model name	: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

❯ lsb_release -d
Description:	Ubuntu 20.10

❯ go version
go version go1.15.6 linux/amd64

Results on master:

❯ go test -benchtime=10s -run=NONE -bench='Inbox' .
goos: linux
goarch: amd64
pkg: github.com/nats-io/nats.go/test
BenchmarkInboxCreation-12       	100000000	      120 ns/op
BenchmarkNewInboxCreation-12    	126825975	      102 ns/op
PASS
ok  	github.com/nats-io/nats.go/test	34.671s

Results from this PR:

❯ go test -benchtime=10s -run=NONE -bench='Inbox' .
goos: linux
goarch: amd64
pkg: github.com/nats-io/nats.go/test
BenchmarkInboxCreation-12        	100000000	      103 ns/op
BenchmarkConnInboxCreation-12    	97371662	      123 ns/op
BenchmarkNewInboxCreation-12     	114624123	      110 ns/op
PASS
ok  	github.com/nats-io/nats.go/test	50.713s

[wallyqs]

Thanks for the PR, I think that since the having to change the inbox is not something that is very commonly done maybe we could do something slightly more simple like replacing the prefix while making the request/request handler: https://github.com/nats-io/nats.go/compare/master...wallyqs:custom-inbox?diff=unified

[simonfxr]

@wallyqs I see, yeah that would work. However it would make using the api a bit more complex for our use case. With the proposed PR we could also use the Conn.NewInbox/NewRespInbox functions. Changing only the inbox used for requests, would mean that we cannot directly use those api parts. Also it feels a bit inconsistent to have different inbox prefixes for different api parts (disregarding the global NewInbox() of course).
Whats your opinion?

[ripienaar]

+1 for doing this so that NewInbox() does the right thing etc, this is also what nats.java does.

[wallyqs]

agree could also make nc.NewRespInbox and old style requests being custom prefix aware as well: 4bea21c?branch=4bea21ce7b9269d68b207b346b7a479662e603e6&diff=unified#diff-1d2fb9af677137c0182213770500dd5625a51ba7286301cb11d0197b21e0f948R3257-R3268

[simonfxr]

@wallyqs What about an inbox prefix aware nc.NewInbox() function? I think that is also what @ripienaar suggested?

[simonfxr]

Any updates on this?

[kozlovic]

Closing since PR #767 has been merged.