IceStorm error reporting hook

[shaver]

While I understand that IceStorm can only really detect errors such as connection closure, it would be nice to be able to register for notifications of those things. In the app I'm developing we broadcast events to subscribed clients fairly often, but there is also other state associated with those clients. If I could find out that they'd gone away from IceStorm, I could tear down that state much more promptly.

Mike

[shaver]

Is this something that ZeroC would take a patch for, assuming that the implementation was up to snuff, or is it not an extension that would be welcomed within IceStorm?

Reading between the lines of the ACM Queue paper makes it sound like Wish uses IceStorm for game-data publication, in which case I would expect them to have a similar problem. Maybe there's a more clever solution that I haven't thought of, which would not be unprecedented.

Mike

[marc]

In general, you cannot rely on detecting TCP connection closure, especially not outside your local network. That's why we are reluctant to add any hooks for detecting TCP connection closure, because it might mislead the programmer into thinking that this is a reliable method for disassociate client-specific state in the server.

In Wish, Glacier is used for session management. When a client goes away, or if a client is idle for a certain time, the Glacier router terminates, and thereby tears down (notifies) a session object. Glacier is not only a firewall, but also a session manager.

[shaver]

I guess I can understand not wanting people to use an unreliable facility under the assumption that it's reliable, but much of IceStorm is already built around a "best-effort" basis. Really, I just want a callback when IceStorm would otherwise spew an error to the console due to not having an endpoint to send a message, etc.

That said, it sounds like Glacier's session management might be what I need, though I can imagine that not every IceStorm-using app will want to add Glacier to the equation. My connections are (perhaps obviously) bi-directional, so I was wary of using ACM to detect overly-idle clients. (23.4.6 says that it "must not be used for bi-directional connections", which seemed pretty clear.)

It looks like I just have to stick the appropriate stringified proxy in Glacier.Router.SessionManager, and I'm away to the races. Will the next release of the Ice book describe the session management capabilities of Glacier in more detail? I'd never have found it if not for your post -- for which many thanks, of course!

Mike

[marc]

Note that if you use bi-directional connections, you must use Glacier anyway.

I can't promise that we will add more info to our Glacier documentation soon. We still have a lot of other things on our todo list. However, it's not that complicated, really. Just as you said, you have to provide Glacier with an implementation of a SessionManager, using the property Glacier.Router.SessionManager.

[shaver]

Originally posted by marc
Note that if you use bi-directional connections, you must use Glacier anyway.

I can't promise that we will add more info to our Glacier documentation soon. We still have a lot of other things on our todo list. However, it's not that complicated, really. Just as you said, you have to provide Glacier with an implementation of a SessionManager, using the property Glacier.Router.SessionManager.

You only need Glacier if you're traversing a firewall boundary, no? I have several cooperating servers involved in my Ice app, and I wasn't planning on making them Glacier to each other. For that sort of information distribution within a trust domain, IceStorm would be ideal (modulo the error-reporting feedback).

I'd offer to send Glacier session manager docs, but I don't think you want a patch against the PDF. Maybe I'll write up a blurb about the property and post it, though I just found demos/Glacier/session, which might suffice for people more literate than me. *blush*

Thanks again,

Mike

[marc]

Originally posted by shaver
You only need Glacier if you're traversing a firewall boundary, no? I have several cooperating servers involved in my Ice app, and I wasn't planning on making them Glacier to each other. For that sort of information distribution within a trust domain, IceStorm would be ideal (modulo the error-reporting feedback).

That's correct. But you said you have bi-directional connections. These are only supported with Glacier. You don't need bi-directional connections for the back end anyway, since their main benefit is to allow callback through firewalls.

[shaver]

Sorry, yes, I was unclear, and conflating two issues.

For my application, I'm using Glacier for these troublesome clients, but my original request was with respect to getting feedback from IceStorm that it received a connection error, so that I could "discard" that client, rather than having every topic notification cause another handful of lines to drop into the server log. So while Glacier's session management will largely solve it for me (though not if one of the servers crashes, since there's no Glacier involved), it's not really a general substitute for an IceStorm error feedback interface.

Mike