 Hi Red Hat Developers, this is Jason with the Red Hat Developers program here at Summit 2017 at the DevZone doing lightning talks. This morning we have John Osborn from Red Hat. He's going to be talking about offloading JEE sessions. Hi everyone, my name is John Osborn, I'm here with Red Hat. I'm a senior developer advocate and I'm going to cover offloading JEE sessions today. So a lot of customers are using technologies like JBoss DAP, Tomcat, they're running traditional JEE apps but one of the problems that they have when they move into a more modern platform like OpenShift is that they want to do things like rolling updates where they have a new application that gets deployed and their code goes through some sort of CICD pipeline and then automated into OpenShift for instance. But if you're running a traditional JEE app which stores stateful data this is actually really difficult to do because the data is inside the application so you can't just take it down right away. So one of the things that we do is for customers is we help them set up JBoss Data Grid. Now JBoss Data Grid is an in-memory distributed cache and can do a lot of things but one of the things that does out of the box really nicely is offload the JEE sessions into JBoss DAP. So this this session we quick crash course into how to do that. So I'll just give a real quick background. JBoss Data Grid is an in-memory distributed store. All the data it stores is in memory. It can actually persist to disk automatically if you want to but traditionally it keeps the data in memory and it makes redundant copies of that data so you can survive failover and server crashes and so forth. And it scales elastically so if I have too much information in memory I can easily scale on the back end and I don't have to worry about that necessarily at the application level. And the way it works is that it uses a distribution method where some of the data gets stored on each node and then redundant copies that data get stored on different nodes. And if a node were to go down well then that's fine it'll just spin up a new node and then it'll do what's how we call straight state transfer where existing copies of the data that are in memory and other nodes will actually transfer to the new node and it'll kind of do the seamless load balancing thing for you. Now you can write apps that that integrate with Jboss DataGrid it's very easy to do and it integrates with a lot of new technologies like Apache Spark, big data technologies. It's a really a robust technology that we have a red hat that's been around for quite some time but if you're using it as Taflo JEE sessions this comes right out of the box and there's actually no code changes required. And just one more thing about it we also do have what's called near caching which is you actually have a cache of your cache so you have something that doesn't need to go over the wire at all it keeps items of that of your data set locally within the same JBM as your application or the same machine as your application for even faster load times. So on OpenShift what this would look like is if you go into the OpenShift service catalog you can quickly spin up Jboss DataGrid instances they automatically find each other and cluster to each other and they'll be spread out across in different containers across multiple nodes. Now those nodes can be bare metal they can be open stack virtual machines or public cloud doesn't really matter to Jboss DataGrid they'll just evenly disperse throughout the cluster. Now I mentioned this is really seamless integration for EAP so and that's what this talk is all about is how to do this so I can configure Jboss DataGrid as a store for EAP and there's several benefits to doing it to doing it this way. The first is that I enable rolling updates of EAP so if I have EAP sessions and they'll have stateful data well if I'm storing the state somewhere else I essentially have a stateless JEE app and I can quickly take down that application without having to worry about losing data so that's really the the main benefit but by doing so it's going to accelerate your CI CD because I can now quickly create development pipelines and roll out new features within my code and I don't have to worry about you know where the state of my data is going. I also reduce the resource requirements of EAP so if you're storing JEE sessions you have to worry about that throughout your testing for for your EAP sizing things like your heap size your max your min max heap size you know all those things cpu requirements you'd have to worry about how many sessions and how large the sessions would be when you actually size out your EAP application if you offload into a data grid data grid is not only going to handle that for you but it can scale elastically so if you end up needing more sessions that are larger you don't have to necessarily worry about you know testing all that out because JbOS data grid is an elastic scalable store in the back end so when you go to when you go to size out your EAP apps you actually only need to worry about how much your application threads and cpus are actually going to use locally and not have to worry about all the sessions one thing that's really nice about this as well is you can actually seamlessly fail over across data centers so JbOS data grid has a built-in feature where if you have a cluster of sessions or have any data really it can automatically fail over that to another cluster that's running somewhere else in another public cloud or on another private data center and this is really important because the way a lot of customers do this now is they use technologies like database replication or sand replication and those are very expensive and this is something that comes out of the box and has been proven by a lot of customers and you do have that built in elasticity but the thing i like the most is the node code changes so i don't have to i don't have to code my application for this this is something that i just press a button and rolls out so how do i do this so the first thing there's really three main steps and it's very easy so the first thing is to configure EAP the infinite span module that comes with EAP as a remote cache so this will tell the EAP settings that you're basically storing the cache data somewhere else and this is just a quick example of what this configuration would look like it's not complete so it'll be it looks good on a slide but this is essentially what you're doing configuring the EAP module to look somewhere else second is you're telling EAP this the specific connections of where to look so if this wasn't in my standalone xml or in my domain xml and it's open up this this one setting and i tell it where the jboss data grid servers are so when i'm in running an open shift you know you would see the the data grid servers across the project name service cluster local you know normally normal service discovery host name and port information here finally you just point your application to your cache so all you have to do is open up your application jboss web xml and just tell it what the cache information it is and the set and the type of data you're storing there so that's your session app so very easy to do and that's pretty much it at the end of all that you'll have something that looks like this right so you'll have your your EAP application and if you want to spin up a new instance that's totally fine it just spins up open shift will now start um brown robinning or load balancing between your new EAP apps and all the data is stored in data grids you don't have to necessarily worry or care about the implementation details of where that all that session data is stored and it's all in memory so it's very fast so i hope that gave you a quick crash course today onto uh offloading of je sessions and jboss data grid on open shifts again my name is john osborn i'm a senior developer at red hat enjoy red hat summit thank you