Francesco Guardiani

> I understand that the Client has to be an abstraction above protocols, but would it make sense to introduce the notion of partition into it ? I don't think...

For the examples in the docs, there is an open issue #153

Is still valid?

Is this solved by https://github.com/cloudevents/sdk-go/pull/491 ?

> You probably won't like this, but protocols like AMQP 1.0 have been designed to support this. 100% agree with @deissnerk, it seems to me we want to replicate the...

After playing with the [multipart experiment](https://github.com/slinkydeveloper/sdk-go/commits/multipart_experiment), i come out with [`MultiMessage`](https://github.com/slinkydeveloper/sdk-go/blob/multipart_experiment/v2/binding/multi_message.go#L3). `MultiMessage` is a `Message` iterator with a `Finish()`. I didn't included this interface in `Message` because it requires dropping...

@antoineco this seems like a serious issue, It could be that on the long run the memory allocated by memory pools are never really freed... Can you provide a profiling...

Thanks! Also upload a cpuprofile (but don't acquire both in the same run)

Ok so i can't really talk for the memory allocated by the container, but about the process itself 10Mb is definitely a reasonable amount of memory to keep the runtime...

I think 10 Mb is quite normal in every golang application that uses some sort of pooling I guess, even ones that doesn't use pooling... I even think it's too...