Could you keep the 'v1.0.0' interface?

[michilu]

I like the new interface. Really, I used the semaphore to control concurrency outside the bus.
And, I hope to keeps both the old interface and the new interface.

• There is the code that depends on the old interface.
• The new interface has a concern as performance is degraded. https://github.com/vardius/message-bus/blob/master/README.md#benchmark

v1.0.0

message-bus/bus.go

Line 82 in c1f01b6

func New() MessageBus {

v1.1.0

message-bus/bus.go

Line 93 in bdb2394

func New(maxConcurrentCalls int) MessageBus {

Ref: dd40db9#diff-ecf9c6bcdc8d97b7f04226e8857c1108L82

[carldunham]

Heh. I was going to suggest the opposite, that the current interface stutters quite a bit. My concern is more aesthetic tho, as Go Stockholm Syndrome kicks in.

[vardius]

First of all @michilu sorry for a very late reply. I meant to reply earlier but after i read your issue at work I forgot to do so after work.

The main goal for v1.1.0 was to reduce the amount of goroutine spawns. By spawning goroutines on subscribe once and keeping them alive. In previous versions many goroutines where spawned each time publish method was called.

Also earlier the concurrency was limited on a global level meaning one queue per all handler of all topics. in v1.1.0 it is limited per topic. Each of topics has it's own queue.

I encourage you to contribute. I am sure together we can workout best performance interface. More use cases gives more insides on actual message-bus usability and performance.

As to the benchmark I suppose we could call b.ResetTimer() after loop which would exclude the startup cost of goroutines.

message-bus/benchmark_test.go

Line 28 in 116e5c3

for i := 0; i < subscribersAmount; i++ {

[michilu]

@vardius Thanks for your reply.
I will think about your suggestion.

My use case that implements with your message-bus is this.
https://github.com/michilu/boilerplate/blob/173e4736f68c188a6300f4a87f8c3de276dddce6/v/bus/bus.go

I want to use a lightweight pub/sub.
Now I implement by channel via genny, like this.
https://github.com/michilu/boilerplate/blob/master/v/topic/topic.go

If you no problem, close this issue.

[vardius]

Would be good to know what is the opinion of other ppl as well.

As to your request we could add new constructor something like this

// NewAsync creates new MessageBus that always spawns goroutines
func NewAsync() MessageBus {
	return New(runtime.NumCPU())
}

which would create new bus with preset number of concurrent calls. maybe we could set it to -1 and then not use buffered channels but call handler directly ?

ideally we create strategy interface (async, sync) and based on that we use buffered channels ?
what do you think ?

[vardius]

I’m closing this issue because it has been inactive for a while. Please use the https://github.com/vardius/message-bus/releases/tag/v1.0.0 for v1.0.0 interface. Keep in mind that by using older release you loose recent bug fixes and futures.

Thank you!