Specify connection when creating Allocation/Admin session for Glacier2

[bernardnormier]

This PR updates the IceGrid code to specify the connection when creating "plain" sessions and Admin sessions via the Glacier2 session managers hosted by IceGrid.

It's not immediately clear why we didn't do it before. I believe the connections represent the correct connections. Maybe an oversight?

See also #2756 (loosely related).

See also #2967.

[pepone]

It's not immediately clear why we didn't do it before. I believe the connections represent the correct connections. Maybe an oversight?

In the original design, when a client sends a heartbeat to Glacier2, Glacier2 would send a keep-alive request to the target session. The lifetime of the session was tied to the Client-Glacier2 connection.

In Ice 3.7, when registering a session with a connection, the reap thread would add a HeartbeatCallbackI, which relied on ACM heartbeats to keep the session alive. However, when a session was created through Glacier2, we didn’t register it with a connection because the Glacier2-IceGrid connection isn’t tied to a single session.

The issue with the new setup is that, as long as a client keeps its session alive, the Glacier2-IceGrid connection remains open. This prevents the reaper from cleaning up any sessions created through Glacier2, as the connection doesn’t close when individual client sessions terminate.

[bernardnormier]

The issue with the new setup is that, as long as a client keeps its session alive, the Glacier2-IceGrid connection remains open. This prevents the reaper from cleaning up any sessions created through Glacier2, as the connection doesn’t close when individual client sessions terminate.

In my view, that's not an issue.

When you create sessions using a Glacier2 router, it's the responsibility of the Glacier2 router to destroy these sessions, except in the case the Glacier2 router--IceGrid registry connection drops (in which case IceGrid cleans up sessions bound to the dropped connection).

Say we have:
client -> Glacier2 router -> IceGrid registry session manager

and the client crash. Then it's up to the Glacier2 router to "destroy" the session object hosted by IceGrid - or at least attempt to destroy it. And that's what Glacier2 router does:

ice/cpp/src/Glacier2/SessionRouterI.cpp

Line 954 in f604fb2

connection->setCloseCallback(

ice/cpp/src/Glacier2/SessionRouterI.cpp

Line 740 in f604fb2

router->destroy([self = shared_from_this()](exception_ptr e) { self->sessionDestroyException(e); });

ice/cpp/src/Glacier2/RouterI.cpp

Line 82 in f604fb2

if (_context.size() > 0)

[bentoi]

The connection close callback was added when ACM heartbeats were added (in 3.6). Prior to the addition of the connection close callback, sessions were only closed based on a keep alive Slice operation being called at regular intervals.

At this time, I believe we didn't want to break compatibility and still allow 3.5 clients to work with Glacier2 3.6 or vice-versa, ditto with different IceGrid/Glacier2 versions...

That's most likely the reason why we still have code that doesn't rely on the connection close callback for destroying sessions. And it's likely that we didn't consider removing this support with 3.7.