ARCast.TV - WCF Session Behavior from Slovenia

Announcer: It's Wednesday, September 26, 2007, and you're watching ARCast TV.

[music]
Ron Jacobs: Hey welcome back friends, this is your host Ron Jacobs, and today we are going to chat with Microsoft MVP, Matevz Gacnik. That's a conversation that I had with him at the conference in Slovenia that I went to in May. Now Slovenia is a beautiful place tucked in between Italy and Croatia there in the Gulf of Venice. It's just beautiful, and we had a great time there learning and talking to people.

Today we're going to talk about Windows Communication Foundation and some work that Matevz has been doing in understanding the way that WCF uses sessions kind of under the covers. It's one of those "gotcha" things that I think architects need to understand. Features don't come for free; there's a cost associated with them. So we're going to listen to Matevz talking about some of the lessons he learned about dealing with sessions and reliable messaging and that sort of thing. Let's go to Slovenia.

[applause and cheering]
Ron: All right. Thank you, thank you.

[applause and cheering]
Ron: Wow! Welcome to ARCast Live from Slovenia and wow this is great to see such a group here. This is my first time in Slovenia and I'm delighted. Wow, I didn't even know you guys were here, but this is a great place. Let me see, I've got to get the name of this place right, is it Portoroz?
Matevz Gacnik: It's Portoroz.
Ron: Portoroz?
Man 1: Yeah.
Ron: Ah, OK. You see, I've got to get that. OK, so I'm...
Man 2: You were close.
Ron: I'm working on it, OK, trying to get my Anglo pronunciation out of the way, right?
Man 2: Yeah. [laughing]
Ron: OK, so I'm delighted to be joined today by three guests. I'm going to let you guys go down and introduce yourself. Tell us your name, where you're from, and what do you do. Let's start here.
Matevz Gacnik: My name is Matevz Gacnik. Well, what do I do? Well, I design large systems around Slovenia, mostly. I'm a Solution Architect MVP. I'm a Microsoft Regional Director for Slovenia and I do a lot of sessions.
Ron: Ah, OK.
Matevz: I talk a lot.
Ron: [laughing] OK, like most regional directors...
Matevz: Yeah.
Ron: ...you're kind of a loud person, OK.
Matevz: Sure.
Ron: Yeah, all right. Good! Wow, so we're here at this NT conference that you guys do and I've been speaking here. It was great to join you guys. So, I want to talk a little bit about some of your sessions since you probably did more than one. You've got to pick one session. What was your favorite session here that you did?
Matevz: From my sessions?
Ron: Yeah.
Matevz: Actually, the last one.
Ron: Yeah?
Matevz: I had three this year. I had a couple of press conferences too, but most of the stuff that I talked about was going on during the sessions.
Ron: OK.
Matevz: And the last one was kind of too technical. I like to talk about strictly technology sessions which target a specific technology and actually a specific part of a certain technology.
Ron: Right.
Matevz: And the last one was actually on message sessions inside WCF, inside Windows Communication Foundation.
Ron: Wow. OK, all right. So educate me, what do you mean message sessions? What is that?
Matevz: Well, Windows Communication Foundation has this notion of an explicit session which a client actually can start, can stop, can terminate.
Ron: huh.
Matevz: But actually depending on the bindings and actually the protocols that you plug in, that you use, there exists a session which is system wide, or actually system based.
Ron: OK.
Matevz: The session gets created whether we like it or not.
Ron: Yeah.
Matevz: And I call them messaging sessions because they depend on the protocol that you're using.
Ron: Right, OK.
Matevz: So, if you turn on WS reliable messaging and reliable message delivery, you get a session.
Ron: Right.
Matevz: It's a message based session whether you demanded it or not.
Ron: OK.
Matevz: So, I talked about that. I talked the about creation of those sessions. I talked about the problems that arise because there are certain limitations regarding the scalability when sessions are introduced. You get a maximum of some number of sessions, and then you're screwed. You have to know what you're doing. It was the most technical talk I gave this year.
Ron: Is this the kind of thing you can turn off if you want to? Say I don't want sessions.
Matevz: Actually you can't. You can't turn off the system session, or the messaging session which is done by the reliable messaging channel or the security channel. What you can do is design the client and the service appropriately so the limitations are not reoccurring.
Ron: All right, if you've got this message session, and you can't do anything about it, it's just there, what can you do on the client or the server so you're doing the right thing with this?
Matevz: There are a couple of knobs inside - for example the reliable messaging element in windows communication foundation, which allow you to terminate sessions, not prematurely, but in time. The defaults specify that a session which is created should not be terminated in less than 10 minutes. It's not terminated in less than 10 minutes for a good reason. If you're doing the reliable messaging, what you need to do is hold the channel open, or hold the session open for some amount of time.

Network errors can do a lot of things. You can get delays; you can get repeated packages or anything. What you can do on the service side is increase the number of maximum sessions, or actual maximum number of sessions. You can decrease the in-activity time-out so the service side drops the sessions sooner so you don't hit the maximum session count so early.
Ron: This is what you were talking about the scalability of the server. Say I want 1, 000 sessions, or whatever, but obviously it's going to take more memory if you do more sessions. Right?
Matevz: Yeah. Especially in the case of the reliable messenger session where you cache the messages. You have to cache the messages just to implement the semantics that you want.
Ron: Reliable messaging is a really interesting and very powerful protocol. Do you think - are people tempted to use this more than they should?
Matevz: Yeah, of course, yeah. Every big functionality which is exposed in a simple way gets over used.
Ron: Oh, it's a new toy, I want to use it. I'm going to turn it on. It's great!
Matevz: [inaudible] [laughs]
Ron: I have to use it. I really need it.
Matevz: It's two elements away. You have to configure two or three elements and you're done. Everything works reliably.

Nobody actually understands what's happening beneath it. So what you get is a lot of problems around the architecture of the application when things are turned on just because they are there.
Ron: This is good. You want to make sure of two things. You're only using it if your requirements really, really need it because it's making the server work pretty hard to accomplish this thing. If you do use it, you need to understand what's going on and how to tune it appropriately, adjust those knobs, so you are not limiting the scalability of your solutions.
Matevz: If you do use it, you have to design the client appropriately; you have to figure the server appropriately.
Ron: So what about the client. We talked about the server. What do you need to do on the client, the same thing?
Matevz: There are a lot of knobs that make you terminate the session in a different way. Right? What you can do on the server side, you cannot terminate the session on the server side without explicitly doing something from the client. By explicitly I mean either waiting on the client for to long, or terminating the session explicitly, or calling a method or an operation which terminates a session.
Ron: OK, OK.
Matevz: What you can do on the server side is, of course, design the interfacing away where you specify this method is terminating the session when it gets called from the client.
Ron: Oh, so you can have a method like close, or something like that, and...
Matevz: Yeah, or you have a special method which closes the session, or have actually the API which gets started by a run operation does some things regardless whether the session is set up or not. And then finishes up with a finishing operation which concludes the session.
Ron: So, is this the kind of thing then, you're thinking on the client side, "Look, I'm going to connect to the server. I'm going to do some message exchange. I'm going to end that connection as soon as possible so I'm being very efficient with the server resources."
Matevz: Depends on the problem that you're solving, right? Because you are efficient in terms of terminating the session. But setting up a session costs a lot too.
Ron: OK.
Matevz: So you shouldn't set up a session and terminate it frequently if you're doing repeated calls to the service, right?
Ron: OK.
Matevz: But what you have to do, of course, is when you create a session you have to know that you have to terminate at some time.
Ron: Yeah.
Matevz: You cannot leave them hanging.
Ron: OK. Very informing.
Matevz: And that's something that actually is mostly problematic in WCF right now, because there is no real guidance on it. Or actually, it's not exposed enough.
Ron: No guidance about how to clean up your sessions?
Matevz: A lot of people. Sure, yeah.
Ron: OK, so what do you see, what kind of symptoms so you see when you've got an application that's not cleaning up sessions?
Matevz: What you get is... Actually, the default for the maximum number of concurrent sessions in Real Communication Foundation right now is ten. So you design a service which uses, for example, a reliable channel. Or uses a secure channel with, for example, Secure Commerization. Right?
Ron: Yeah.
Matevz: Or both.
Ron: OK.
Matevz: What you get is ten sessions by default, and that means ten clients which do not close the sessions appropriately and you leave the eleventh one hanging.
Ron: Wow. So, you've got a server sitting there that can only talk to ten clients, that's it?
Matevz: Yeah. If the clients don't close the sessions appropriately or you don't design the interface appropriately. Right?
Ron: Oh, OK.
Matevz: So, if you use a stateless method, for example, a process message method, and you push a binding which requires a reliable channel. Given ten clients, the eleventh one won't go through.
Ron: OK, but you're saying like if your use a reliable session or you use kind of a session oriented communication. But if you do something that's stateless, like a typical web service call, then you don't have this limitation.
Matevz: The problem is that the protocol underneath the typical web service call could not be stateless, so you get a session anyway. So you don't have to have stateless processing to get the session.
Ron: Oh, OK.
Matevz: Those matter. If you've got the process message method, which only processes statelessly, it doesn't matter because when you demand a reliable messaging channel, which most of the people actually do because it's there and it's so simple to expose, what you get is a session on the server side.

You have to terminate it explicitly on the client by calling proxy door closers or something on the underlying class that implements communication, right?
Ron: Right.
Matevz: Nobody's doing it, because nobody had to do it in ASP.NET web service.
Ron: OK, but if you didn't do a reliable channel. Say you just kind of took all the defaults, are you still going to have this problem?
Matevz: It depends on what is the default. If you take, for example, there's a special binding called Basic HTTP Binding in WCF which communicates, serializes things as if it would be ASP.NET Web Services.

It's a classical RPC style semantics. There's no probable protocol session underneath it, so you don't create one, and everything's OK.
Ron: Oh, OK.
Matevz: As soon as you turn the new binding, which is, of course, why you most probably want to run Indigo...
Ron: You mean the WS Star binding?
Matevz: Yeah. The first one you plug in, you've got a session because the defaults are set up in a way that you've got a session.
Ron: Oh, OK. Very interesting.

[segue]

[music]

See, that is very interesting, because sometimes we have these wonderful product features, and we make them so simple to use. Yeah, just put a little attribute on here and we take care of the rest. But you really need to understand that at least something about what the rest is, and sometimes it doesn't always come through in the product documentation. We always are focusing on how easy things are.

But if you really want get behind the scenes, let me recommend a great book by a good friend of mine, Juval Lowy. He's written a book called "Programming WCF Services." I turned in my copy to page 145 where there's a nice little table where he talks about the various kinds of bindings and how the session mode of those bindings works. He covers the fact that depending on what you're doing, what features you ask for, what kind of sessions you get.

So it is possible to learn these things my friends. You just have to know where to look. Hey, we'll see you next time on ARCast.TV.
Announcer: ARCast.TV is a production of the Microsoft Architecture Strategy Team, www.ARCast.TV.