Channel mono

[pmackowski]

This PR has been triggered by issue#41

There have been added following properties to both SenderOptions and SendOptions:

• Mono<? extends Channel> channelMono

• BiConsumer<SignalType, Channel> channelCloseHandler

There is another subtle change referring to discrepancy of caching channel creation

• Sender#send uses connectionMono.map(CHANNEL_CREATION_FUNCTION).cache()
• Sender#sendWithPublishConfirms uses connectionMono.map(CHANNEL_CREATION_FUNCTION)

I removed cache() in Sender#send

[pivotal-issuemaster]

@pmackowski Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@pmackowski Thank you for signing the Contributor License Agreement!

[michaelklishin]

Are you sure you want to log every channel closure as info? Some environments have high channel churn.

[pmackowski]

I would prefer to log it as debug. It is extracted from here
channel close

[pmackowski]

I changed logging level to debug

[acogoluegnes]

@pmackowski Thanks for this contribution! Why didn't you add a Mono<Channel in SendOptions to override the one in Sender? Do you think this level of customization isn't necessary?

[pmackowski]

@acogoluegnes I did it initially but finally reverted changes in SendOptions revert commit.
The reason was that I could not figure out simple and clean solution without additional changes
e.g. I am not sure how to calculate options in the following method in Sender

public Mono<Void> send(Publisher<OutboundMessage> messages) {
        return send(messages, new SendOptions());
}

Let's take exceptionHandler into account with its default value and suppose it is also defined in SenderOptions. Should we always use the one from SendOptions because it has higher priority or the one from SenderOptions where user defined it and was not aware of SendOptions at all?

If you don't mind I can try to suggest some solution, unless I overlooked something.

[acogoluegnes]

The one in SendOptions would be null by default so Sender#getChannelMono() would be used by default (and the one from SenderOptions if it's been provided). If a channel mono is to be provided in SendOptions it would be used first. Does that make sense? I think so, and it does not break the existing code.

[pmackowski]

Yes, it makes sense with null properties in SendOptions. I will revert reverted commit and create a new PR.