On Thursday Feb 16 I will be at Spring I/O in Madrid speaking about Running Spring Apps on the Cloud with Heroku at 12:40.

Hope to see you there!

1. Signup for a Heroku account
   
   
2. Install the Heroku plugin locally:

   $ play install heroku

3. Create a Play (1.2.3 or 1.2.4) app:

   $ play new foo --with heroku

4. Deploy the app:

   $ play heroku:deploy foo

   You should see something like:

   ~        _            _ 
   ~  _ __ | | __ _ _  _| |
   ~ | '_ \| |/ _' | || |_|
   ~ |  __/|_|\____|\__ (_)
   ~ |_|            |__/   
   ~
   ~ play! 1.2.4, http://www.playframework.org
   ~
   ~ Deploying app to Heroku
   Listening for transport dt_socket at address: 8000
   Project directory: /home/jamesw/Desktop/foo
   Read Heroku API key from /home/jamesw/.heroku/credentials
   Created new ssh key pair (heroku_rsa) in: /home/jamesw/.ssh
   Added the heroku_rsa.pub ssh public key to your Heroku account
   Created a .git directory for your project
   Added and committed all of the local changes to the git repo
   Created app: cold-night-1511
   http://cold-night-1511.herokuapp.com/
   Added git remote: git@heroku.com:cold-night-1511.git
   Deploying application via git push
   Application deployed
   ~ App Deployed

   Note: I haven’t figured out how to pipe the git push output to the screen yet, so be patient when the app is being git pushed. It’s working, just takes a minute.

5. Check out your Play app running on the cloud! Use the URL in the “heroku:deploy” output. This should work with new and existing Play apps.

All of the code for the Heroku Play module is on GitHub. There is more I want to do with this (scaling, logs, etc) and your contributions are certainly welcome! Keep checking back here for updates and let me know how it goes!

• Cincinnati JUG on January 26th
• Detroit JUG on January 31st
• MongoDB Boulder on Febuary 1st

Hope to see you there!

Here are steps you can follow to get started running Java on Heroku with Eclipse and your browser:

Prerequisites) Install the EGit and Maven (m2e) Eclipse plugins into your Eclipse. In Eclipse select the “Help” menu, select “Install new Software”, from the “Work With” drop-down menu select “All Available Sites”, and enter “EGit” in the filter box. After the plugin list has loaded (could take a minute) then select the “Eclipse EGit” plugin, select “Next”, and finish walking through the wizard to the plugin. Then do the same for the Maven Plugin “m2e”.

Step 1) Go to java.herokuapp.com and select an application template. In the screencast I used the “Simple Java Web App with Maven and Tomcat” option since it uses the familiar WAR packaging and Tomcat. Enter your email address and click the “Go!” button. This will create a copy of the template, upload it to Heroku, and assign you as the owner of the app. When the app is created you will see some instructions and a link to the application running on Heroku.

Step 2) You should have received an email from Heroku indicating that an application has been shared with you. If this is your first time using Heroku you will need to click the account setup link in the email in order to set your password on Heroku.

Step 3) If this is the first time you have used Heroku then you will need to create and associate a ssh key with your Heroku account. This will be used to authenticate you for git file transfers (to copy the application to/from Heroku). One way to create a new ssh key and associate it with your Heroku account is via key.herokuapp.com. Just enter your Heroku username / password and a new ssh key will be created, associated with your account, and then downloaded. You will then need to setup Eclipse to use that key. Go to the “Window” menu -> “Preferences” -> search for “SSH”, select “Add Private Key…”, select the private key that was just downloaded, and then select “OK”.

Step 4) Now you are ready to import the created project into Eclipse. Select the “File” menu -> “Import”, select “Project from Git”, select “Clone…”, paste the git URL into the “URI” box (you will find the git URL in the java.herokuapp.com instructions or in the email from Heroku), and select “Next”.

Eclipse will fetch the branches of the remote git repository and should display just a master branch. Select “Next” and then “Finish”. A local copy of the project will now be on your computer. Now select “Next”, select “Import as general project, select “Next”, and then select “Finish” to complete the import. From here you can take a few other steps to setup the project for local development. First, install the m2e-wtp connector, create a new Tomcat server in Eclipse, change the web module context root to “/”, and then you can just right-click on the project and select “Run As” -> “Run on Server”.

Step 5) Make a change to the app that you will be able to see when the new version is pushed to Heroku. For instance, add something to the index.jsp file. If you have setup your Eclipse for local development then you should be able to test this change locally before pushing it to Heroku.

Step 6) To commit the changes to the local git repository, right-click on the project, select “Team” -> “Commit…”, enter a commit message, and select “Commit”.

Now that the changes are in the local git repository they can be pushed to Heroku. Right-click on the project, select “Team” -> “Push to Upstream”. This will send your change to Heroku and then Heroku will run the project’s Maven build and redeploy the changes. When the process has completed you will see the details of the push and the Maven build.

Now refresh (or load) the app in your browser and you should see the changes.

That should be enough to get you started. As you dive in further check out the Heroku Dev Center for a lot more details on using Java on Heroku. Let me know if you have any questions.

• San Diego Java User’s Group on Tuesday, January 17th
• Silicon Valley Web JUG on Wednesday, January 18th
• The Capital District Java Developers Network on Thursday January 19th

Hope to see you there!

• Boulder, Colorado – December 13
• Phoenix, Arizona – December 14
• Portland, Oregon – December 20

I hope to see you there!

Step 1) Download and install Play Framework 1.2.3

Step 2) Create a new Play app from the command line and then move to the new directory:

play new playbars
cd playbars

Optional Step 3) If you want to work in an IDE then you can run one of the following commands and then open the generated project in your IDE:

play idealize

play eclipsify

I won’t walk though the IDE specific steps here, but you can refer to the Play documentation on IDE integration if you want to get that setup. Note that IntelliJ IDEA has great support for Play Framework with a console right in the IDE.

Step 4) Start the Play server from the new project’s directory :

play run --%test

This starts Play in test mode which will automatically recompile any changes we make to the application. No packaging, redeploying, or restarting servers will be needed.

Step 5) Open the application in your browser:
http://localhost:9000

The default page provides you with great Play documentation on how to get started. But we will soon be changing that page. If you want to view the documentation locally after we change the page you can use these links:

• Documentation
• Play JavaDoc

Step 6) Lets start by creating a new JPA entity. Keeping it very simple, lets create a new “app/models/Bar.java” file containing:

package models;
 
import play.db.jpa.Model;
 
import javax.persistence.Entity;
 
@Entity
public class Bar extends Model {
 
    public String name;
 
}

This entity uses the standard JPA Entity annotation but also extends the Play Model class which provides some nice conveniences which you can read more about in the Play JPA docs. I’m using just a plain public property on this class but you can also use the Java Bean getter/setter stuff in you like.

Step 7) Create a simple unit / integration test for this Bar object by creating a “test/BarTest.java” file with the following contents:

import org.junit.*;
import java.util.*;
import play.test.*;
import models.*;
 
public class BarTest extends UnitTest {
 
    @Test
    public void integrationTest() {
        Bar bar = new Bar();
        bar.name = "a new bar";
        bar.save();
        assertNotNull(bar.id);
        assertTrue(Bar.findAll().size() >= 1);
        bar.delete();
        assertTrue(Bar.findAll().size() == 0);
    }
 
}

Step 8) Setup the default database by editing the “conf/application.conf” file and uncommenting the following line:

# db=mem

This sets up the default database to be an in-memory database.

Step 9) Run the application’s tests by opening the following URL in your browser:
http://localhost:9000/@tests

Select “BarTest” and then click the “Start!” button. The test should pass.

Step 10) Add the following two methods to the “app/controllers/Application.java” file:

    public static void addBar(Bar bar) {
        bar.save();
        index();
    }
 
    public static void listBars() {
        renderJSON(Bar.findAll());
    }

The addBar method takes a Bar, saves it, and then redirects back to the index page. Play will automatically parse request parameters and populate the Bar object. The listBars method queries for all of the Bars in the database and then outputs then as serialized JSON.

Step 11) Play has a very flexible model for mapping URLs to controllers. Lets setup two new routes that will map URLs to the new methods we’ve added to the Application controller. Add the following lines to the “conf/routes” file but make sure you either add them above the “Catch all” or simply remove the “Catch all” route:

POST    /                                       Application.addBar
GET     /bars.json                              Application.listBars

The first route handles HTTP POST requests to the “/” URL and handles them with the Application.addBar method. The second route handles requests to the “/bars.json” URL and handles them with the Application.listBars method.

Step 12) Lets add a FunctionalTest that will actually make requests to the Controller and test that our new routes and controller methods are working. Add the following method to the “test/ApplicationTest.java” file:

    @Test
    public void barTest() {
        Response addBarResponse = POST("/", APPLICATION_X_WWW_FORM_URLENCODED, "bar.name=foo");
        assertStatus(302, addBarResponse);
        Response listBarsResponse = GET("/bars.json");
        assertIsOk(listBarsResponse);
    }

This test adds a new Bar by doing an HTTP POST to “/” and passing it some form encoded data. Then a request is made to “/bars.json” and the response is checked to make sure there wasn’t an error. Since there isn’t a DELETE method (which could easily be added) there isn’t a good way to clean up what this test does.

Run the ApplicationTest Functional Test in the Play Framework Web Test Runner:
http://localhost:9000/@tests?select=ApplicationTest.class

Because the test didn’t clean up after itself you can now see the JSON from “/bars.json” in your browser by visiting:
http://localhost:9000/bars.json

Step 13) Now it is time to create the actual web UI for this application. A combination of plain HTML (via Play’s Groovy templates) and jQuery will be used. Play Framework uses a convention to render the HTML from the “app/views/Application/index.html” template when Application.index‘s render method is called. In the “index.html” file and you will see:

#{extends 'main.html' /}
#{set title:'Home' /}
 
#{welcome /}

You can also take a look at the referenced “app/views/main.html” file to see what the base template looks like. It does the standard HTML page stuff and then inserts the body of the “index.html” page into the “#{doLayout /}” section. The “main.html” template also loads jQuery and provides a way to insert some JavaScript into the head section of the page. In the “index.html” file, replace the “#{welcome /}” line with a form that will allow users to create new bars:

#{form @addBar()}
    <input type="text" name="bar.name"/>
    <input type="submit"/>
#{/form}

The “#{form @addBar()}” syntax is Groovy that creates a form tag and sets the form action to the URL that corresponds to the Application.addBar method. You can test this out by loading this page in your browser:
http://localhost:9000/

The form should be functional now. Enter the name of a bar and click the submit button. Because the “addBar” method calls the “index” method, after the POST, the browser is redirected back to the index page. You can verify that the data is being saved by loading the bars.json page again.

Now lets add some Ajax / jQuery to the “index.html” page that will get the JSON data and display it in the page. Add an empty ul tag with an id of “bars”:

<ul id="bars">
 
</ul>

Now we will insert the JavaScript into the correct place in the page by setting the “moreScripts” variable:

#{set 'moreScripts'}
<script type="text/javascript">
    $(function() {
        $.get("bars.json", function(data) {
            $.each(data, function(index, item) {
                $("#bars").append("<li>Bar " + item.name + "</li>");
            });
        });
    });
</script>
#{/set}

Using jQuery this bit of JavaScript adds a function handler for when the page is loaded, then in that function it makes a get request to “bars.json”. That request has a function handler for when the result comes back from the Ajax request. Inside that function handler the data is iterated through and each “bar” is appended into the page element with the id of “bars” – the ul tag.

Try out the application and make sure that you can still add new bars and see the list of all the bars in the database.

Now that everything works locally, lets deploy the app on the cloud using Heroku.

Step 1) Create an account on Heroku.com, install the Heroku Toolbelt and git and then login to Heroku from the command line:

heroku login

If this is the first time you’ve done this then new ssh keys for git will be created and associated with your Heroku account.

Step 2) Each application on Heroku has a Postgres database for testing. To use that database when running on Heroku we need to configure it. Play applications on Heroku run in “prod” mode. To set the database to use the Heroku database add the following lines to the “conf/application.conf” file:

%prod.db=${DATABASE_URL}
%prod.jpa.dialect=org.hibernate.dialect.PostgreSQLDialect
%prod.jpa.ddl=update

The default way to provide database (and other resource) connection strings to an application on Heroku, is through environment variables. The DATABASE_URL environment variable will contain the database host, name, username, and password. Play Framework knows how to handle that information and setup the JDBC connections.

Step 3) Heroku uses git as a means to uploading applications. Whether or not you use git for your SCM tool you can use git as the tool to upload an app to Heroku. In the root directory of your project create git repo, add the files to it, and then commit the files:

git init
git add app conf public test
git commit -m init

Note: Instead of doing a selective “git add” you can create a “.gitignore” file containing the files to not add to the git repo.

Step 4) Now we will provision a new application on Heroku using the Heroku CLI. Each application you create gets 750 free “dyno” hours per month. So as a developer you can use Heroku for free and only pay when you need to scale beyond one dyno. On the command line create a new application using the “cedar” stack:

heroku create -s cedar

This creates an HTTP endpoint and a git endpoint for your application. You can also use a custom name and point your own domain names at the application.

Step 5) The application is ready to be deployed to the cloud. From a command line do a “git push” to the master branch on Heroku:

git push heroku master

Once the files have been received by Heroku, Play Framework’s precompiler will be run, Heroku will assemble a “slug file”, and then the “slug” will be deployed onto a dyno.

Step 6) You can now open the application in your browser by navigating to the domain outputted following the “heroku create” or by simply running:

heroku open

You’ve built a Play Framework application with JPA, JSON, & jQuery and then deployed that application on the cloud with Heroku! Now get the code and check out a demo on Heroku. Let me know if you have any questions.

Jetty has recently added support for a pluggable session state manager. This allows us to move away from sticky sessions and session replication and instead use external systems to store session state. Jetty provides a MongoDB implementation out-of-the-box but presumably it wouldn’t be very hard to add other implementations like Memcached. Jetty has some good documentation on how to configure this with XML. Lets walk through a sample application using Jetty and MongoDB for session state and then deploy that application on the cloud with Heroku.

First lets cover some Heroku basics. Heroku runs applications on “dynos”. You can think of dynos as isolated execution environments for your application. An application on Heroku can have web dynos and non-web dynos. Web dynos will be used for handling HTTP requests for your application. Non-web dynos can be used for background processing, one-off processes, scheduled jobs, etc. HTTP (or HTTPS) requests to your application are automatically load balanced across your web dynos. Heroku does not use sticky sessions so it is up to you to insure that if you have more than one web dyno or if a dyno is restarted, that your users’ sessions will not be lost.

Heroku does not have any special/custom APIs and does not dictate which app server you use. This means you have to bring your app server with you. There are a variety of ways to do that but the preferred approach is to specify your app server as a dependency in your application build descriptor (Maven, sbt, etc).

You must tell Heroku what process needs to be run when a new dyno is started. This is defined in a file called “Procfile” that must be in the root directory of your project.

Heroku provides a really nifty and simple way to provision new external systems that you can use in your application. These are called “add-ons”. There are tons of Heroku add-ons but for this example we will be using the MongoHQ add-on that provides a MongoDB instance.

With that in mind lets walk through a simple application that uses Jetty’s MongoDB-backed sessions. You can get all of this code from github or just clone the github repo:

git clone git://github.com/jamesward/jetty-mongo-session-test.git

First lets setup a Maven build that will include the Jetty and MongoDB driver dependencies. We will use “appassembler-maven-plugin” to generate a script that starts the Jetty server. Here is the pom.xml Maven build descriptor:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.heroku.test</groupId>
    <version>1.0-SNAPSHOT</version>
    <name>jettySessionTest</name>
    <artifactId>jettySessionTest</artifactId>
    <packaging>jar</packaging>
 
    <dependencies>
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-webapp</artifactId>
            <version>8.0.3.v20111011</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-nosql</artifactId>
            <version>8.0.3.v20111011</version>
        </dependency>
        <dependency>
            <groupId>org.mongodb</groupId>
            <artifactId>mongo-java-driver</artifactId>
            <version>2.6.5</version>
        </dependency>
    </dependencies>
 
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>appassembler-maven-plugin</artifactId>
                <version>1.1.1</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>assemble</goal>
                        </goals>
                        <configuration>
                            <assembleDirectory>target</assembleDirectory>
                            <programs>
                                <program>
                                    <mainClass>com.heroku.test.Main</mainClass>
                                    <name>webapp</name>
                                </program>
                            </programs>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
 
</project>

The “appassembler-maven-plugin” references a class “com.heroku.test.Main” that hasn’t been created yet. We will get to that in a minute. First lets create a simple servlet that will store an object in the session. Here is the servlet from the “src/main/java/com/heroku/test/servlet/TestServlet.java” file:

package com.heroku.test.servlet;
 
 
import java.io.IOException;
import java.io.Serializable;
import java.util.Date;
 
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
public class TestServlet extends HttpServlet {
 
    private class CountHolder implements Serializable {
 
        private static final long serialVersionUID = 1L;
        private Integer count;
        private Date time;
 
        public CountHolder() {
            count = 0;
            time = new Date();
        }
 
        public Integer getCount() {
            return count;
        }
 
        public void plusPlus() {
            count++;
        }
 
        public void setTime(Date time) {
            this.time = time;
        }
    }
 
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
 
        HttpSession session = req.getSession();
 
        CountHolder count;
 
        if(session.getAttribute("count") != null) {            
            count = (CountHolder) session.getAttribute("count");
        } else {
            count = new CountHolder();
        }
 
        count.setTime(new Date());
        count.plusPlus();
 
        System.out.println("Count: " + count.getCount());
 
        session.setAttribute("count", count);
 
        resp.getWriter().print("count = " + count.getCount());
    }
 
}

As you can see there is nothing special here. We are using the regular HttpSession normally, storing and retrieving a Serializable object named CountHolder. The application simply displays the number or times the servlet has been accessed by a user (where “user” really means a request that passes the same JSESSIONID cookie as a previous request).

Now lets map that servlet to the “/” URL pattern in the web app descriptor (src/main/webapp/WEB-INF/web.xml):

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    version="2.5">
 
    <servlet>
        <servlet-name>Test Servlet</servlet-name>
        <servlet-class>com.heroku.test.servlet.TestServlet</servlet-class>
    </servlet>
 
    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>*.ico</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>Test Servlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>
 
</web-app>

I put a servlet mapping in for “.ico” because some browsers automatically request “favicon.ico”, and those requests if not mapped to something will map to our servlet and make the count appear to jump.

Now lets create that “com.heroku.test.Main” class that will configure Jetty and start it. One reason we are using a Java class to start Jetty is because we are trying to avoid putting the MongoDB connection information in a text file. Heroku add-ons place their connection information for the external systems in environment variables. We could copy that information into a plain XML Jetty config file but that is an anti-pattern because if the add-on provider needs to change the connection information (perhaps for failover purposes) then our application would stop working until we manually updated the config file. So our simple Main class will just read the connection information from an environment variable and configure Jetty at runtime. Here is the source for the “src/main/java/com/heroku/test/Main.java” file:

package com.heroku.test;
 
import java.util.Date;
import java.util.Random;
 
import org.eclipse.jetty.nosql.mongodb.MongoSessionIdManager;
import org.eclipse.jetty.nosql.mongodb.MongoSessionManager;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.session.SessionHandler;
import org.eclipse.jetty.webapp.WebAppContext;
 
import com.mongodb.DB;
import com.mongodb.MongoURI;
 
public class Main {
 
    public static void main(String[] args) throws Exception{
        String webappDirLocation = "src/main/webapp/";
 
        String webPort = System.getenv("PORT");
        if(webPort == null || webPort.isEmpty()) {
            webPort = "8080";
        }
 
        Server server = new Server(Integer.valueOf(webPort));
        WebAppContext root = new WebAppContext();
 
        MongoURI mongoURI = new MongoURI(System.getenv("MONGOHQ_URL"));
        DB connectedDB = mongoURI.connectDB();
 
        if (mongoURI.getUsername() != null) {
            connectedDB.authenticate(mongoURI.getUsername(), mongoURI.getPassword());
        }
 
        MongoSessionIdManager idMgr = new MongoSessionIdManager(server, connectedDB.getCollection("sessions"));
 
        Random rand = new Random((new Date()).getTime());
        int workerNum = 1000 + rand.nextInt(8999);
 
        idMgr.setWorkerName(String.valueOf(workerNum));
        server.setSessionIdManager(idMgr);
 
        SessionHandler sessionHandler = new SessionHandler();
        MongoSessionManager mongoMgr = new MongoSessionManager();
        mongoMgr.setSessionIdManager(server.getSessionIdManager());
        sessionHandler.setSessionManager(mongoMgr);
 
        root.setSessionHandler(sessionHandler);
        root.setContextPath("/");
        root.setDescriptor(webappDirLocation+"/WEB-INF/web.xml");
        root.setResourceBase(webappDirLocation);
        root.setParentLoaderPriority(true);
 
        server.setHandler(root);
 
        server.start();
        server.join();
    }
 
}

As you can see the MongoSessionManager is being configured based on the MONGOHQ_URL environment variable, the Jetty server is being configured to use the MongoSessionManager and pointed to the web app location, and then Jetty is started.

Now lets give it a try! If you want to run everything locally then you will need to have Maven 3 and MongoDB installed and started. Then run the Maven build

mvn package

This will use the appassembler-maven-plugin to generate the start script which sets up the CLASSPATH and then runs the com.heroku.test.Main class. Before we run we need to set the environment variable to point to our local MongoDB:

• On Windows:

  set MONGOHQ_URL=mongodb://127.0.0.1:27017/test

• On Linux/Mac:

  export MONGOHQ_URL=mongodb://127.0.0.1:27017/test

Now run the generated start script:

• On Windows:

  target\bin\webapp.bat

• On Linux/Mac:

  sh target/bin/webapp

Test the app in your browser by visiting:
http://localhost:8080/

Refresh the page a few times to verify that the count is increasing.

This is just testing one instance of the application which isn’t very exciting since part of the purpose of moving the session out of memory and into an external system is to handle scalability. So lets start up another instance of the app on a different port and make sure that the session is consistent between both servers. In another terminal window / command prompt start up a second server on port 9090:

• On Windows:

  set MONGOHQ_URL=mongodb://127.0.0.1:27017/test
  set PORT=9090
  target\bin\webapp.bat

• On Linux/Mac:

  export MONGOHQ_URL=mongodb://127.0.0.1:27017/test
  export PORT=9090
  sh target/bin/webapp

Now in your browser make a few requests to:
http://localhost:9090/

Verify that the session is consistent between the two servers.

Now lets deploy this app on the cloud with Heroku. As mentioned earlier we need a file named “Procfile” in the root directory that will tell Heroku what process to run when a dyno is started. Here is the Procfile for this application:

web: sh target/bin/webapp

To create and deploy the application you will need to install git & the Heroku Toolbelt, create an Heroku, and since we will be using add-ons you will need to verify your Heroku account. Each application your create on Heroku gets 750 free dyno hours per month. So as long as you don’t go above that and you stick with the free tier of the MongoHQ add-on, then you won’t be billed for anything.

Login to Heroku using the heroku command line interface:

heroku login

If you haven’t already setup an SSH key for Heroku then the login process will walk you through that.

In the root directory of this project create the app on Heroku with the “cedar” stack and the free MongoHQ add-on:

heroku create --stack cedar --addons mongohq:free

Upload your application to Heroku using git:

git push heroku master

Open the application in your browser:

heroku open

If you want to add more dynos handling web requests then run:

heroku scale web=2

To see what is running on Heroku run:

heroku ps

If you want to turn off all of the dynos for your application just scale to 0:

heroku scale web=0

To see the logging information for your application run:

heroku logs

To see a live version of this demo visit:
http://young-wind-7462.herokuapp.com/

Well, there you go. You’ve learned how to avoid sticky sessions and session replication by moving session state to an external MongoDB system that can be scaled independently of the web tier. You’ve also learned how to run this on the cloud with Heroku. Let me know if you have any questions.

BTW: I’d like to thank John Simone from Heroku for writing most of the code for this demo.

• Tuesday December 6 at the Central Ohio JUG
• Thursday December 8 at the Orange County JUG

The sessions will teach you how to deploy Java, Play! and Scala apps on the cloud with Heroku. Hope to see you there!