Good afternoon, everybody. Welcome to WebObjects deployments for Leopard Server. And my name is Menkit C. I'm a senior WebObjects engineer. Today, I'm very happy to be here with you guys. And we're going to talk about some new features on our WebObjects runtime. So today, I'm going to talk about four brand new WebObjects features for Leopard Server. The first and very important one, which is the performance boost enabled by using Java new I/O. And we are going to introduce a new threading model, and we're going to show you what do we mean by performance boost and let you experience it. So the second features we're going to talk about is Load balancing with Apache 2.2 Mod Proxy Balancer. So, starting in Leopard, we are deprecating the mod web objects proprietary load balancing module in the favor of using standard Apache 2.2 Mod Proxy Balancer. And the third feature is we're going to talk about load balancing with Tomcat 5.5 adapter.

We are doing some experimentations, exploring options, and we'll talk about this very soon. the four features, which is also very important, which is I'm very happy to tell you guys that starting Leopard, WebObjects is going to have built-in JMX support with every world application instances and I'm going to talk about some new APIs and how you guys can leverage it and do a demo. So to begin with, we're going to start with Let's talk about the performance analysis we have done with JMX.

So what we have done is that we tried to-- in that part, we introduced a new threading model. And we tried to adopt the Java NIO. And we do a quick performance analysis back in Cupertino. And what we did was that we just load the standard file upload examples that were shipped with the Xcode DVD. and then we load the server on a MacBook 1.83 core-dued Intel processor with 2 gigs of RAM. And the interesting thing is that we are actually using the load generating on a Mac Pro quad processor with 4 gigs of RAM. Why we do that? Because we just need to generate a lot of loads to try to kill the NIO server, but we just cannot. So let's take a look at what numbers we got.

So in terms of response time performance, and here's what we got with KASIC, which is the old world. The average response time was 61 milliseconds. The minimum response times was 47 milliseconds, and the 90% line, that means that 90% of the requests are being handled by a single WebObjects instances within 63 milliseconds. So what about, that was using the WebObjects 5.3, the what you guys shipped, what we shipped with, and what you already have. And with the new threading model and the NIO runtime, we have this. So-- Hey, thank you.

So our average response time was cut from 61 milliseconds to 11 milliseconds, and our minimum response time is cut from 47 milliseconds to 7. Most of our requests, 90% is cut from 63 milliseconds to 12 milliseconds. So who can do the math? That's six times faster. Thanks. So after we talk about the response time, what about scalability?

So when you develop applications from a customer perspective, your customer want to get the response really quick. That's why we talk about response time first. But from an application administrator perspective, you want to have a server that's super scalable so that you don't have to buy tons and tons of machines to serve your customer. So let's take a look at the throughput performance that we have done and measured back in Cupertino.

In terms of throughput performance, using the classic worlds, which is a stream-based blocking I/O using the WebObjects 5.3 World Worker Threads model, we get-- We were able to handle 30 requests per second. And using the new threading model, and using the Java NIO, we get 119. So how much more requests we can handle with the new I/O? It's four times more requests per second.

So now what's next? So now we have shown you this performance boost using the new NIO and the new threading model. Now the next thing that we are going to talk about is how could that be possible? I mean, how does it work with the new threading model? Now we all live with world worker threads. Now you're telling me that these world worker threads is not relevant anymore? What's the deal? Why do we get rid of the worker threads? And what is so special about the NIO? So with that, we're going to dive into the NIO, the new threading model and the Java NIO architecture. So to start with, using Java NIO, that's something called Connection Watcher. What it is is it's a single thread that's just watching for incoming connection. So what is so special about this? It is special because unlike the classic model, you have one thread watching one socket with the Java NIO and the new threading model, you actually have one thread that's playing the role of a connection watcher and now it's watching hundreds and thousands of socket channels. So that means that you actually save a lot of server resources. There's no more one thread per socket, which was the case in the classic world. So what happened when the connection watcher discovered us a ready socket channel? It is going to-- heading off the connections to a worker thread pool. And then what happened to the worker thread pool? The worker thread pool would select its managed worker threads and distribute the connections to each of them. And then what happened to this three worker threads pool? Now, three keywords. One, they work directly with clients. Two, they work independently. Three, they work independently without supervision of its thread pool. So there's no overhead like paying back and forth. So three is that they actually work in parallel. So and we would, like later in the slides, we'll see why that's so important that they were in parallel independence because we need that to achieve maximum concurrency.

So now, as you see, all these three workers for us, the one in purple and the one in red, the one in green, they're all doing good, serving as clients, and clients are on different networks. So everything seems to be good. Now, what happens when trouble comes? Like that.

You see that? The worker thread that's in purple is servicing a client on a slow upstream network. So what does it mean? That means that your server is actually on a very fast network. It's ready to receive lots and lots and lots of data in a very fast manner. But you're too bad. Your client is just on a slow upstream network. It cannot give you data quick enough. So what happens in the classic world? In a classic world, then the worker threads would just sit still, standing still, blocked on read, and then consuming the server resources and do no useful work. Because in the old world, once a request come in, we have a worker threads assigned to it. It grab really tight to the request. And then when the client is not ready, it will still hold it, and it would never let go. But in the new world, what did they do?

They actually tell the, they actually return itself to the worker thread pool. And then what would the worker, and then what happened to the other two threads, the red and green? Remember three keywords? The first one was direct. I show you from the previous slides that they were direct. Like, take a look.

They were directly working with clients. And now I'm going to show you that they're working, like, independently of each other. The first worker thread's in purple because there's no more work for them. So they return itself to the thread pool. But the other two, it's continued. handling the request. It's processing the business logic. So how the worker thread pool deals with the worker threads is going to do this. It's going to make a note to the connection watcher and say, hey, you know what? Watch that client. We have to watch them because the client is on a snow upstream network. There's no more work for us. So as you see, the worker threads in purple, it's going to go back to the worker thread pool and getting ready to do useful work rather than, unlike the classic model, that the worker thread would just sit idling, blocked, consuming server resources, and doing no useful work. So now... What happened when the slow client is finally catch up and is ready to send more data? But we have nobody home, nobody home to receive the data. So what happened will be the worker thread would selecting a worker threads. Now what's so special about the new threading model is that This worker threads could be the same worker threads that surfaced the clients before, or it could be a totally different one. Because as I said before, unlike the old model, that once a request, when a transaction comes in, a worker threads will hold on to those transactions and will hold on to it until it completes. But in the new model, they don't. When there's no more work, the worker threads will return itself to the worker thread pool and doing useful work. And that means that a worker threads could be reading in one and then writing response for another minute, and then processing request, doing business logic in another minute, and guess what? They're all independent, they're all swappable, and they can be serving three different, totally three different transactions at various different time, doing different things. That's how we achieve maximum concurrency, by breaking the tie between one thread per transaction. So, now, Now, the worker thread pool has selected a worker thread that's, in this case, it's the same worker thread. Now, as you see, before free keywords, remember, direct, independence, and concurrence. You will see that the purple worker thread is reading the request, and the other two is writing the response because they're working independently. So, what happened next is, now everything is good.

What happens when trouble comes again? Look at the second client. parents. It is on a slow downstream network. What does that mean? That means that your server, again, it's on a very fast network. It want to push data really, really fast to its clients, but the client just cannot keep up.

It doesn't receive the data quick enough. As a result, the client is not ready. The worker thread has nothing to do. Unlike the blocking I/O, the worker thread would just sit still, idling, blocked, consuming server resources. In the new threading model and NIO, the worker threads will return itself to the thread pool and then the rest of the worker threads will work independently in parallel without any interference. So, how did the worker thread pool handle the worker thread? It would recycle it and it would get it ready to handle a different client and while it's doing that, it will make a note to the connection watcher and say, "Hey, watch that guy. That guy is on a slow downstream network. When he becomes available, let us know." And I will let the worker thread pool to select one of its managed worker thread to handle it.

Now finally, the clients on a slow downstream network has become available, but there's nobody home to send his data, to send him any data. So what's going to happen? So the worker thread pool is going to select a worker thread. It could be the same thread. It could be a totally different thread. So in this case, it's a different thread. Before it was red. Now it was yellow. So after they select the worker threads, they continue servicing their requests in a direct, independent, and in parallel manner. They're writing response. So now the next thing is that you see the green worker threads is fast on both ways. fast on upstream and it's fast on downstream, so of course it's going to finish first.

So when it's finished, it will return itself to worker thread pool and then the transaction complete. What happened to the other two? The other two would continue working with its clients. And then finally when they were done, then they returned themselves to the pool and they were able to return to the pool. There we go, we complete a illustration of how life looks like with the new threading model and Java NIO. Let me get some water.

So after we have talked about-- after we have shown you some performance analysis we have done in Cupertino headquarters, after we have talked about some theories and understand how things work, so the next question you are going to ask me is, ManKit, is this relevant to me? Can I replicate this kind of performance enhancement in my home production environment? To enable you to do that, let's talk about some configuration settings, something that you actually need to do to enable this.

So let's talk about how do you turn it on. To turn on the NIO adapter is really easy. You set it to woe-nio-enable=true. And notice that that's a stashd in front of it. So what does that mean? That means that you can pass this command line using standard Java notations and do the stashd on command line when you launch your Java applications. Or if you are a big time, long time WebObjects fan, you would like to use world properties file, that's fine. You can just specify that in the property files. Both would work. So the moment you turn on this world NIO enable flag to true, you're running with the new threading model. You're running based on NIO, and your world worker threads becomes irrelevant.

So there's no hybrid mode. You cannot say, OK, I want NIO on, but then I also want the worker threads on at the same time. No, there's no such thing. And the reason we don't do this thing is because if you turn NIO on, you have one worker threads running the connection watcher and watching hundreds of thousands of requests. But at the same time, if you're on the same server, same instances running the blocking IO, it's going to spawn a lot of worker threads up front, and it will consume a lot of server resources. This is something I'll try to avoid. That's why there's no hybrid mode. So it's a big switch. You either move or you either stick around. So next, this will be WoW NIO blocking enabled. So that seems a little bit confusing. So what is it?

So, NIO is basically two parts. One is doing non-blocking IO and you have a multiplexer. Well, in Java, terminology is having a selector to watch the register socket channel. That's another part side of it is that with the NIO, it's actually operating in terms of bytes buffers. So, the reason I introduced this flag is because when I'm developing this, I get into a situation that, hey, something goes wrong. Is it some bugs in the connection watcher, or is it the way it handles it? Remember, the worker's report would notify the connection watcher every time that this client is not ready to process data.

So we turn this blocking enabled to true, and then that would make the worker threads just call thread yield. So instead of notifying its thread pool, which we in turn notify its connection watcher to watch that slow climb. So this is basically a debugging thing. Then you guys, I'm pretty sure you guys may run into it when you try to vote nio-enabled, you get a true, and something breaks.

try that with blocking enabled to go to true and see if it fixed your problem. And please, file the bugs in bugreport.apple.com. We need you guys to help mature the frameworks. Okay, that's enough digression. Next, let's talk about woe-nio bytes buffer factories. In Lepre 5.4, we introduced a woe-nio bytes buffer factories. So what, so, and the most important flag is called direct bytes buffer enabled. So what is it? What is direct bytes buffer?

Okay, direct byte, okay, that's two types of buffer. One is bytes buffer, the other one is direct bytes buffer. For bytes buffer, it's consuming HIP space, it's managed by the VM, and with direct byte buffer, it's using non-HIP space, so what's the benefits of that? The benefit is, if it's using non-HIP space, it's closer to the low-level stack, so that means that when you do networked I/O operations, or file I/O operations using non-HIP space memory, because it's closer to the native system call, the I/O is going to be faster. So what's the catch? The catch is the creation cost of the direct bytes buffer is going to be larger than its traditional bytes buffer. So to address this concern, we introduced second configuration setting, which is raw NIO preheated by 12-foot pool size. So what is it?

So let's say if you are running a small business, if you have an intranet, and at the most, you only have 10 clients accessing your application. You don't want to set this preheated by its buffer pool size to really large number, because at the most, there will be 10. So setting it up really big, that means that the consequences is the launch time will be relatively increased. So we want to make sure that you set this number to a reasonable size so that you can pay the construction costs up front. So when your server is up and running, then the user would have quick response time because it would take benefits of using non-HEAP memory and the cost of using non-HEAP memory is taken care of during launch time.

So the next thing is NIO defaults by buffer size. The default is 8192. So what is it? So we have a bucket and a water tab. So the water tab, in this metaphor, the water tab is actually your networked, bandwidth and the buckets is your bytes buffer size. So what happens if you're on a snow network and you expect there's only very little data that's coming in, but you set the bytes buffer size to really big like 1M, 2M, then you see this.

The water is dripping. Now it's done. But take a look. The bytes buffer, you allocate it. You told the WebObjects runtime to allocate it. It's huge. But it's never getting used to its full capacity. The utilization is so low. You're wasting a lot of server resources. That's the way to kill scalability. So please don't do that. So if you know that you only have a very small data coming in burst mode and your network is slow, use a small bucket. So that when the data comes, water dripping in, and it will use the full size. So it's all about, in terms of performance on deployment, it's all about efficient use of several resources.

And, okay, what about the other side of the corn? What happens if you have a really thick pipe and you use small buckets? As you see before, I'll play this again. If you see before, your buckets fill up really fast, and what happens when it fills up? Your networks want to push a lot of data to you, but you don't have enough bytes buffer size to hold it. So you have to stop the tab. You have to pause the network. And then you have to replace the buckets. So if you're on a fast network and expect lots of data coming, then you use a larger bucket. So set the bytes buffer size to larger. So like that. it would fill up the whole bucket and then you don't have to stop it frequently. So what next?

Remember the connection watcher? The connection watcher is implemented with a class called WoW NIO multiplexer. And we introduced a configuration settings called multiplexer timeout. So what is it done? Why do we need to do this? Because, again, it's about efficient use of several resources. You want to set the timeout, let's say, to 30 minutes. So you can track it. we're going to have a host to the whole NIO multiplexer for you. So you can do something like this. If within 30 minutes, if you don't see there's any ready socket channels, that means there's no clients hitting your server for 30 minutes, then you may want to do something. Like, let's say, email the system application system administrator saying that, hey, our server is busy. Our server has been idling. Maybe we should use the server and deploy different instances and retire these instances. and something like that.

Right. And the next thing is, it's adapted to listening cube size. Now, for those people, how many people who come to previous years of WebObjects performance optimization session? Can I raise your hand? Now, last year, we talked about, okay, the default listening cube size was four. Now, this is not relevant anymore. Because with the new 3D models, we We do some performance testing. Four doesn't seem to be the optimal for the new threading model.

And I encourage you guys to try it out, characterize it, and file a bug report, tell us how it works in your production, in your station environments, and we would mature these frameworks together. So the defaults for the new NIO, it would be 128. So next, there's a preheated worker thread pool size. So what does it mean? So if you have a Mac Pro, you want to set this at least to 4, because you have 4 cores.

And so you want to -- this is basically you want to see how many concurrents requests you want to handle, you expect to handle. If you set it too big, again, it's consuming a lot of server resources. If you set it too small, you're not fully utilizing your CPU. So the default will be 16. It may change. It's just a DP. good news is that you can actually specify this yourself based on your need. Oops, sorry. Okay, so after we have talked about these configurations, assuming that you guys are all excited and try it out at home and it seems to be great, you just tell your boss, "Hey, great, we learned about this new threading model and we learned about the new IO and everything seems to work." But your boss asks you, "How do you know? How do we know we are done?" So let's talk about some performance graph.

I'm going to talk about two graphs. One is throughput load graph. The other one is the response time graph. Now, I encourage you guys to do something similar to your production environments, which is now when you start adding load, The throughput is going to increase. The response time is going to increase, but not that much, because your server is still under utilization.

What happens when there's more and more users hitting your server? Then you would start keep on increasing again. So the response time will grow, but not by that much. The rate is low, maybe three degrees or something. Throughputs is still growing linearly. It's still all good. So what happens if the load keeps coming and we don't do anything?

Then increasing more load, you actually, the throughput instead of increase is decrease. Why? Because you have reached a very high utilization and you should do something. Like think about deploying more instances, using more server. What happens if we don't do anything? Or we keep just monitoring it, assuming that don't worry about this mankits, don't worry about him. It will just work, crossing our fingers. Then if you hit this buckle point, when more user comes in, boom, it's dead. Your throughputs would decrease exponentially and then your response time was increased exponentially.

So basically you're just thrashing, not doing any useful work. So after that, So let's do a quick summary of what we have talked about so far. We talked about the performance number. One, we talked about the performance number. Two, we talked about the theories, like how the new threading model works and how the NIO works. And now we talked about configuration setting. We talked about analyzing the performance on a production environment. And now, next thing, I'm going to talk about load balancing. As we said, once it hit buckle points, your instance is dead. So we need to start thinking about load balancing while you hit your saturation point, or way before you hit saturation point at best. So with that, I'm going to talk about load balancing with Apache 2.2.

With this, starting in Leopard, we are going to use mod proxy balancer instead of the mod web objects that were Apple proprietary. And I think it's a good thing that we move on to Apache Community because you can always get a nice new view for Apache and it's actively being developed.

So in Leopard, some of you guys probably see this slide in another session. So we actually have a GUI in Leopard server, the server admin applications, so that you can specify your application cluster using load mod proxy balancer. So yes, you can use Apache frontend to distribute load to WebObjects backend. Right, and by the way, WebObjects is running faster than Ruby and RHEL, and is much more scalable than Ruby and RHEL. WebObjects is still alive and is moving forward.

So after this, I'm going to-- so we talk about the GUI. So what about those people who actually use command line? How many people-- let's do a quick survey. How many people here would prefer using a GUI piece where you still have? OK? So how many people who would actually-- I do all my system administration with command lines. I do SSH in a data center.

Okay, so starting in Leopard server, WebObject is going to take care of both audience. We have the fun end and we have the, you can configure and administer your application on command line using SSH. So how do we do that? Five step. The first step is you need to use SCP securely copy your executable into your remote host. Step two, you generate the launch e.plist file. Cloud on a remote host. So let's talk about LaunchD for a second. In WebObjects 5.3, there's something called VotasD. So what it does, it's actually trying to keep track of the healthiness of your applications.

And they send live bits. And if you don't get the live bits in a timing manner, then it will thought that it was dead. It will recycle. It will restart it, and something like that. And Apple is pushing LaunchD. And we're getting along with them. So we're jumping into launchd. And the benefits of this is that you get rid of a lot of problems that you guys may have been experiencing with Wotastd.

And so the third, let's go back here. The third step is after you generate the launch.plist file, you're going to call, you're going to SSH into your machine and call launch control load the actual plist that you just generated before. And then from that moment on, Your WebObjects instances are starting and running. And then if it dies, the launch day picks it up and we start it again. There's no more WOTASD. So that means that there's no more close rate problem if you're deployed on Apache.

Thanks. So it seems like people do experience a close-range problem with WebObjects 5.3 in Apache 1.3. But the good thing is that we are moving to Apache 2.2. Thank you. So, and then the fourth step is to create a XTDBD stash WebObjects.com file. that's a hoax in Java Monitor. Like how many-- let's do a quick survey. How many people who use Java Monitor? Please raise your hand. OK, now Java Monitor has been example sourced. And you guys-- Okay, so in the example source, there's actually a new tab that I put together really quick. Then it would basically do this. If you have existing deployments environments, they all deploy with Wotacity. They all deploy on Apache 1.3 adapter. Now to move to Apache 2.2, there's one quick shortcut for you guys.

Fire up your Java monitor, and you click on a tab called Migration Tab. And the moment you click on that one, you will see that the httpd-webobjects.conf file will be spirited out for you on the webpage and you can copy and save it onto local disk and do SCP and use that file.

Thanks. There's also some other features in the migration tab in Java Monitor, which is you can specify a SSH identity file, and then it would actually move the files for you. So it would make it even easier. So the last step, the fifth step, is of course called Apache Start, or if you haven't started, or Apache Graceful. So that's concluded with Apache 2.2 low balancing stories. Let me get some water. Thank you. So what next? We are probably talking about load balancing strategy. What are the other load balancing strategy? What about using hardware load balancer? Well, we are not going to talk about load balancing using hardware load balancer, but it would certainly work.

And so instead of talking about heart rate and low balancer, we're going to talk about low balancing with Tomcat's 5-5. So let's talk about it for a few minutes. So why are we doing this? Well, because... that was people, so what is it, blow balancing with Tomcat 5.5?

Well, basically it is a filter that is set onto Tomcat and it doesn't have to set onto Tomcat, it can set into any J2EE container. I knew that a certain customer that was actually trying to sell it to your management and using web objects for a J2EE shop, like if they use WebSphere or WebLogix and you just, because they don't know about the power of web objects and how easy it is to use, and you want to just develop one part of the applications and to use WebObjects, yes, you can do that. We are doing this experiment, experiments, and please tell us if you like this, tell us that you like this, then we'll see what we can do.

So one very important point that my manager always reminds me during rehearsal, which is, make sure that we understand this node balancing adapter is not the same thing as servlets deployment. It is not the same thing as you develop your application, you web your application into a true raw bundle, and then every draft framework gets shoved into the bundle, and then the whole WebObjects application is in a servlets. No, that's not what we're experimenting right there. So instead, we actually have a filter, which will talk to different instances running outside of the container.

So how do we do that? There's five steps, very similar to doing load balancing with Apache. The first step is you need to secure-- use SCP to copy your world bundle-- more executable into your remote host. Step two, you generate the launch.plist files. And in Leopard, I believe that in Leopard, you can actually... So how do you generate this launch.plist file? There's open source tools called Lingle. You can use it with a GUI and configure it. You can use a VI, or you can grab your WebObjects application instances and you do this. let's say, hollow world, and then you do stashd, roll launchd enabled, and if you launch it with the appropriate access privileges, it will generate the file for you and dump it in the correct place. So it will count as an elaborate, but I believe that that portion of the code might be commented out.

So the first step is that you need to call launch control, load the library and then launch the plist. The fourth step is that you need to create a row adapter config.xml file so that the load balancer filter would know how many instances were out there. Last step, you start your container. So with that, let's do a quick demo.

demo machine please. Okay, so what do we get here? So we're gonna show you how to use the Tomcat adapter to do round-robin load balancing with sticky session support. So with that, I would bring up three terminal for my three instances, and then I would cd into that directory, And then I will launch them. Now watch this. Do you see that's a stashd j session ID equal to the number? And let me open up another terminal and show you something. So that's here.

So I am sitting into the library web objects configuration folder, and then I'm going to catch this. You see that? That's an instance ID. When you launch your instances-- let me bring this up. So when you launch your instances, stashd jsessionid up on the top screen equal to 1 must be matched with your world configured.xml file. It says instance ID equal to 1. If you specify it as 1 and you specify it to 10, I'm sorry. It's not that smart. Web of objects is cool, but not that smart. That they can read your mind. So you have to make sure that they match.

Okay, let's create this. And then, now I'm starting one instance as... Let's move it aside. And I'm starting the second instances. Move it aside. Now I'm going to start the... the third instances, move this aside, and after I start three instances, it's starting, Okay, so that's some networking issues here. So let's do logo. Network is back. So what it does is it's a simple application that when you click this button, it just updates the counter. And you see that the session is the same. And so let's start Tomcat.

So as you see, I started Tomcat. And see, now I try to access it, which is here. Now I started transaction and take a look at-- I want you guys to pay attention at the upper-- let me bring it down. I want you to pay attention right here.

Do you see that? J session ID equal to 2. And then when I click this, it's going Contrary increase incorrectly, JSessionID stick with two. And what happens if I have a new user come in? Let's delete this and hit it again. And then, counter restart. And you see, JSessionID is equal to three now. So it's doing round robin. So that's next. Now, updated a few times, it's doing one. So it's actually doing round robin successfully with sticky session support. And that concludes my demo for Tomcat. Slide, please.

So what next? The next thing is JMX. So then that's part of the reason why we do Tomcat, because Tomcat is Java. It's more close to-- Tomcat is Java, and we have built-in JMX to pop up web objects. And we can do a lot of interesting things if we move to Tomcat. like such as using the advanced cost loading mechanisms to do some interesting things. We'll have a demo.

So let's talk about troubleshooting with JMX. So in JMX-- In JMX, we introduce some new API. The first new API we introduce is the role application. In role application is register and bin. Why do we want to do that? Because... Like in the past, you used Wotasty and used all these light bit things to see whether your instances are healthy and running. And I believe that we can do better than that. You can actually define your own healthiness of your instances using JMX. You can specify how much memories that your instances should have and stuff like that. And then you can track different users, set up different conditions. If certain assertion fails, then you want to lock that transaction to JConsole and stuff like that. We'll have a demo for that.

And then the next API we introduce is unregistered nbin. Yeah, obvious. You have register, you have unregister. And then here, get nbin server. So every WebObjects application instances would have a built-in ambient server. That means that you can do some interesting thing. Let's say, for example, if you have a web page-- if you have web applications, you have one page called call, let's say, Hello Man Kids or Hello World, then you can actually use JMX Advanced Class Loading. If you see a box there, you can actually use JMX Advanced Class Loading without shutting down your instances. And you can do the same, like, unregister it, and then register it, and then update it on the fly. But it's not built in without runtime, but it's totally possible it can be done.

And if you want this feature, let us know, and we can see what we can do. But that feature is not a part of the Leopard preview disk. So another API we introduced is the get JMX domain and set JMX domain. So let's have a demo with JMX.

You can see. OK, so with that, we're going to start a World JMX demo machine. And Chuck at Wall, our intern who does cool photo viewer applications from yesterday, is going to help us demo this. So to do this, take a look. I want you guys to pay attention at here. Stashd.com.sun.management.jmx.remote. Could it show? If you're running Java 1.5, you want to turn this on.

If you're running Java JDK 1.4.2, you want to turn this on, plus you want to download an optional package from Sun so that you can use the JMX. And with Java 1.6, when they shift, this flag is not less than Siri. So Chuck, can you launch this for us?

So the application is launching. OK. OK, we have some network problems here. OK, so what does this application does? This application is a simple application. It asks user for inputs. So it expects the numbers from 0 to 10. So Chuck, can you launch JConsole? So you see in JConsole, you can actually do it locally, remotely, and that's in this case, because we're running on the same machine, let's do it locally. Can we click Connect? Bottom, lower. Yep, there you go.

OK. OK, looks like we have minor problems. OK, there we go. It seems working. OK, in JConsole, take a look. There's a summary tab which tells you how many threads are there, what's the heap size, and all this usage. Can we click on the memory tab for a sec?

In this, you see there's a heap space measurement thing, meter, and there's a non-heap space. With the new threading model and NIO, you'll see non-heap space go up a lot, but not using as much heap space. Unless your application code use lots of heap memory. So and then can you click on the threads? So here's the interesting thing. Now, in this pane, you can show all the worker threads, what are they doing, and can you click on one of them?

So as you see, like before JMX, when your application hangs or does not respond as quick as you expect, what do you do? You're just guessing what it does, build lots of locks. But with JMX, you actually know exactly what state it is on. And you have a stack trace. So next time when your application has run into issues, you actually can fire up JMX and look at all the threads.

And then you will know whether this EOF, Enterprise Objects frameworks is deadlocking on you, or you have some problem with Apache adapter that they have all this thing that's hanging all your records threads. So OK, so class, can we go to class? So this will show you how many classes you will load in on your runtime. And let's talk about nbin. Things will get more interesting.

So here, we have three things. Thanks, make it bigger. So nothing seems to be exciting. So Chuck, can you go back to the application, please? Let's start of inputting some good numbers, like 3, 5, or something. OK, we said that the user submitted a 5. Go back to JConsole. Nothing happened. Try another number, 7, let's say.

OK, go back to JConsole. Nothing happened. Now, here's a user that's bad. Let's try click like-- give a number out of range. Let's say 11. And then look at the J console. Boom, you see it locked that as a transaction coming with that host. Can we make this bigger, please?

that it actually submits the number 11. So in this simple application, we are trying to show you that with JMX, we can do conditionally registration. Like in this trivial example, it illustrated how much you can do when it comes to EOF. Let's say if you have EOF applications that you expect that you would only fetch, like each user have a default editing context in the session, and you expect that each user should have only, let's say, 10 toys, right?

But all of a sudden, the user fetching all the toys in the database. Now, with JMX, you can do this conditionally. You can only track the user that trying to do something that you specify that is not expected behavior. And, yeah. And we encourage you to try this out. And that concludes the JMX demo. Slide, please.

OK, oh, there's one little slide missing. That's OK, I'll talk about it. So there's four new features that we introduced in LibreServer. One is the NIO and the performance enhancement and the new threading model. Two is a load balancing with Apache 2.2 adapter using Mod Proxy Balancer. Three is an experimental Tomcat adapter. You can use it on different J2E container. Again, as my manager always reminds me to say this, make it explicit. It is not the same thing as bundling your application into a true raw bundle and running the entire WebObjects application as a server, because it's heavyweight. It is running as a-- so with our experimental Tomcat adapter, it's actually a filter that's living on a J2E container. And then all your WebObjects application is running outside of the container. So in terms of performance, it would be very similar to what you get without using the container. The fourth, the last, very important feature is the JMX. It is just a beginning, and we plan on having some other interesting JMX stuff, like more standard ambience.