Track nrepl-messages per connection

[bbatsov]

While discussing with @expez some issues related to #1399 it became apparent that with the dynamic dispatch and dispatch to multiple connections the current *nrepl-messages* buffer is mostly unusable as you can really figure out which message went where.

We need to either have separate messages buffers per each connection or add connection info the the messages we log right now. Probably option 1 would be better. At any rate we're not shipping 0.10 without something like this.

@expez @Malabarba Any comments?

[expez]

The smallest change would be to just add another kw pair: connection "my-connection" to the message. The kw pair would be ignored by the middleware, and only be useful in the message log, but at some point we might benefit from having that information available down there too.

Having separate message buffers makes comparison more cumbersome, which is probably most of what we're going to do when debugging.

[bbatsov]

If we add it to the messages all responses should include it as well, otherwise this will become super messy. Message id tracking is per-connection, so you'll still need a way to determine the correspondence between requests and responses on a connection level. I understand your point, but it seems to me this will be more work.

[expez]

Message id tracking is per-connection, so you'll still need a way to determine the correspondence between requests and responses on a connection level.

If you know the message with id n was for connection c then the reply with id n is also for connection c, right?

While this requires some manual work, I kind of think this is 'good enough'. None of us will be using this feature very much so it's unlikely to cause much frustration.

[bbatsov]

As someone who gets to receive a lot of output from this buffer to debug it I definitely don't want to do any manual work. I want to see something and immediately understand what's going on.

If you know the message with id n was for connection c then the reply with id n is also for connection c, right?

The problem is that you might very well get in some situations the same ids from different connections. That's unlikely to happen often, but it's not unfeasible. Especially if you often toggle between clj and cljs.

[Malabarba]

Maybe I missed something but I think we're over thinking this.
Received replies already have a session keyword, don't they? Just create a messages buffer for each session.

[bbatsov]

You have two sessions per connection (at least right now). There's also the possibility of session overlap if you're connected to several servers.

[Malabarba]

You have two sessions per connection (at least right now).

Then, if the second (tooling) session is ever used, it will be logged to its own buffer too. Sounds like a plus. :)

There's also the possibility of session overlap if you're connected to several servers.

How is a session ID calculated? I always thought it was a semi-random hash or something.

[bbatsov]

We should check the source. I just know it's guaranteed to be unique per server.

Then, if the second (tooling) session is ever used, it will be logged to its own buffer too. Sounds like a plus. :)

Still, users will have hard time mapping session ids to connection names. I'm pretty sure about this.

[bbatsov]

Btw, we should also consider that cider middleware requests & responses currently don't have a session associated with them and that all connections share the same request ID counter.

[bbatsov]

I've stuffed sessions to all requests and went with @Malabarba's suggestion for now. Mapping to connections is not hard, but has a few small implications:

• the connections are known only to cider
• you have to go through the list of connections to see their sessions
• you have to extract the connection "designation" and apply it to the messages buffer

The current solution, while not ideal, is simple and gets the job done (more or less).

[Malabarba]

This is implemented. Though, as mentioned on gitter, perhaps we can reduce the number of buffers created.