User specified connection name

[vikinghawk]

Provide an option for a client to specify a "friendly name" for a connection. This would show up in the management plugin top-level connections screen in addition to the current name column. The current name "ip:port" is definitely useful, but can become unusable when you have a bunch of connections from the same ip. The "friendly name" could be used to provide client application specific details and make it easier during troubleshooting to locate specific connections.

Discussion: https://groups.google.com/forum/#!topic/rabbitmq-users/hLSoNqcxeKA

[michaelklishin]

Effort: medium because it will involve updating client libraries.

[michaelklishin]

I'm happy to do the client libraries part of this issue.

[michaelklishin]

A quick glance at what changes will be required makes me think it should only go into 3.7.0.

[hairyhum]

We can use client-properties field in connection.start_ok frame to specify connection name.
We already report client properties in management and can just change formatting for connections table in management.
And client libraries can introduce API for setting this client property as "connection name" or just use existing API to set it.

[michaelklishin]

That was the plan, more or less.

On 6 abr 2016, at 16:42, Daniil Fedotov notifications@github.com wrote:

We can use client-properties field in connection.start_ok frame to specify connection name.
We already report client properties in management and can just change formatting for connections table in management.
And client libraries can introduce API for setting this client property as "connection name" or just use existing API to set it.

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub

[hairyhum]

Then we can add this to management plugin and clients in 3.6.x.
There will be no breaking changes.

[hairyhum]

We can also change log messages to support client provided names.

[michaelklishin]

Sure but in addition to the TCP tuple-based names we have today.

On 6 abr 2016, at 19:06, Daniil Fedotov notifications@github.com wrote:

We can also change log messages to support client provided names.

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub

[michaelklishin]

I should expand on the comment above.

We cannot completely replace the connection name(s) we have for several reasons:

• TCP tuple-based ID are used to close connections or get more specific information on them. We absolutely cannot break this for existing systems.
• User-provided names are not guaranteed to be unique. TCP tuple-based names are (per node).
• Per-vhost connection limit #500 still uses TCP tuple-based names heavily.

So the user-provided name, when present, should be listed in a separate column (and on the connection page), not replace the name we have. It will be a useful — and entirely optional — piece of information, not a new connection identification scheme.

[michaelklishin]

One thing about using client properties that I'm of two minds on is that it's going to work on a per-connection factory basis in the Java and .NET clients. Perhaps this can be seen as a quirk of those two clients, as Ruby, Erlang, Node, Go clients all should effectively have it on a per-connection basis due to how their APIs are structured.

[hairyhum]

I'm not sure if it makes sense to implement per factory setting. We can add optional parameter to newConnection/CreateConnection method to start a connection with specific name.

[michaelklishin]

Yes, looking at the code, that should be about as hard as it was for custom executors.

[binarin]

Should this custom name go in logs?

[michaelklishin]

As an additional piece of information, perhaps.

On 31 may 2016, at 15:30, Alexey Lebedeff notifications@github.com wrote:

Should this custom name go in logs?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

[Freakachoo]

Is that possible to add connection_name property to response in a list of channel on /api/channels request?
There is property: connection_details, and would be very useful to have custom connection name there too.

[michaelklishin]

Please post your ideas and suggestions to rabbitmq-users.