LiveRebel FAQ

LiveRebel

  1. How do I get started with LiveRebel?
  2. How to generate the liverebel.xml file using Maven?
  3. How to configure an EAR with LiveRebel?
  4. How to configure a WAR with LiveRebel?
  5. How to configure a JAR with LiveRebel?
  6. How to use the command-line interface (CLI)?
  7. Can I set up LiveRebel Command Center web interface behind a reverse proxy?
  8. What types of changes can LiveRebel handle?
  9. How does LiveRebel work with changes other than those on the above list?
  10. Can I verify the new version for compatibility at build time?
  11. How to verify the new version for compatibility with the old one using Maven?
  12. How to verify the new version for compatibility with the old one using Ant?
  13. How do I update an application?
  14. What happens when I press Update?
  15. How are classes updated?
  16. How does LiveRebel work in a cluster?
  17. How does LiveRebel affect performance?
  18. How do I rollback an update?
  19. I have a bunch of third-party JARs, will LiveRebel manage them too?
  20. How is LiveRebel licensed?
  21. If we stop our JEE container, disable LiveRebel and start the server, what will happen to the application version?
  22. If we stop our JEE container, disable LiveRebel and deploy our application with usual means and start the server, what will happen to the application version?
  23. If we stop our JEE container, deploy our application with usual means and start the server, what will happen to the application version and what should I look out for?
  24. How to install Tomcat with LiveRebel enabled as Windows service?
  25. How to install LiveRebel Command Center as Windows service?

Question: How do I get started with LiveRebel?

Answer:

First of all you need to download an unzip the distribution. Once you’ve done that you can start the LiveRebel Command Center by running bin/lr-command-center.cmd on Windows or bin/lr-command-center.sh on Unix/Mac OS X/Linux.

This will startup the UI for LiveRebel and you can access this via opening your browser at the URL printed or by navigating to http://localhost:9001.

The Command Center will guide you through the initial configuration:

  1. Configure the LiveRebel agents to run on each of your servers
  2. Add liverebel.xml to your applications

After that you can easily manage the deployed application versions using the Command Center Web UI, command-line interface or the REST API.

Question: How to generate the liverebel.xml file using Maven?

Answer:

For maven managed projects you don’t need to write the file by hand. We have developed a plugin that will generate and add the liverebel.xml to the artefact. The plugin is hosted at Maven central. To generate the liverebel.xml you need to add the following section to your pom.xml file.

<build>
    ...
    <plugins>
        <plugin>
            <groupId>org.zeroturnaround</groupId>
            <artifactId>jrebel-maven-plugin</artifactId>
            <!-- Optional configuration -->
	    <configuration>
	       <name>${project.artifactId}-development</name>
	       <version>${project.version}-${maven.build.timestamp}</version>
	     </configuration>
             <executions>
                <execution>
                    <id>generate-liverebel-xml</id>
                    <phase>process-resources</phase>
                    <goals>
                        <goal>generate-liverebel-xml</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
   </plugins>
   ...
</build>

Question: How to configure an EAR with LiveRebel?

Answer:

For the deployed EAR (either directory or archive) and the archives uploaded to the LiveRebel Command Center:

  1. Add a liverebel.xml into the EAR root directory containing the application name and version. E.g.
  2. <application>
      <name>com.mycompany:MyBigApp</name>
      <version>2.3</version>
    </application>
  3. Provide each module with a liverebel.xml only including the module name. (No version, it would be ignored.) E.g.
    <application>
      <name>com.mycompany:MyWebModule</name>
    </application>

    Each JAR module must contain a liverebel.xml in its root directory.
    Eech WAR module must contain a liverebel.xml under WEB-INF/classes.

  4. Provide each WEB-INF/lib JAR file you want to be managed by LiveRebel with a liverebel.xml only including the library name. (No version, it would be ignored.) E.g.
    <application>
      <name>com.mycompany:MyLibrary</name>
    </application>

    This is only required for libraries you want to update using LiveRebel. A liverebel.xml goes to the root directory of a JAR file.

Question: How to configure a WAR with LiveRebel?

Answer:

For the deployed WAR (either directory or archive) and the archives uploaded to the LiveRebel Command Center:

  1. Add a liverebel.xml under WEB-INF/classes containing the application name and version. E.g.
  2. <application>
      <name>com.mycompany:MyWebApp</name>
      <version>2.3</version>
    </application>
  3. Provide each WEB-INF/lib JAR file you want to be managed by LiveRebel with a liverebel.xml only including the library name. (No version, it would be ignored.) E.g.
    <application>
      <name>com.mycompany:MyLibrary</name>
    </application>

    This is only required for libraries you want to update using LiveRebel. A liverebel.xml goes to the root directory of a JAR file.

Question: How to configure a JAR with LiveRebel?

Answer:

For the deployed JAR (either directory or archive) and the archives uploaded to the LiveRebel Command Center:

Add a liverebel.xml into its root directory containing the application name and version. E.g.

<application>
  <name>com.mycompany:MyLibrary</name>
  <version>2.3</version>
</application>

Question: How to use the command-line interface (CLI)?

Answer:

Ensure that the Command Center is running and fully configured. You can then use the CLI utility bin\lr-cli.cmd on Windows or bin/lr-cli.sh on Unix to fully script the update process.

Running bin\lr-cli.cmd help will show the help screen for the command-line utility. To connect to the LiveRebel Command Center the CLI utility needs the authentication token you can get from https://localhost:9001/profile/index or corresponding page in your installation.

Question: Can I set up LiveRebel Command Center web interface behind a reverse proxy?

Answer:

If you would like to serve LiveRebel Command Center web interface through a reverse proxy then you can use the contextPath variable to force LiveRebel web application to a specific context path. Example: export JAVA_OPTS="-DcontextPath=/my-very-own-path" and then you can access it via https://yourhost.com/my-very-own-path.

Question: What types of changes can LiveRebel handle?

Answer:

LiveRebel handles all changes to resources (.css, .html, .js, .jsp, etc) and the majority of changes to classes (excluding changes to type hierarchy) and configuration (support for configuration changes depends on framework/server/tool in question). LiveRebel preserves all application state, but does not create new state.

The following type of changes to classes are unsupported:

  • Replacing the superclass
  • Implementing a new interface

Because LiveRebel cannot create new state the following types of changes may have undesired effect:

  • Adding new instance field or renaming an existing one will cause existing objects to have it initialized to null
  • Changing constructors will only have effect on objects created after the update
  • Generally changes to various initializers will not take effect on existing objects

However LIveRebel does support new static fields and changes to enums.

LiveRebel supports changes to framework/server configuration with plugins. You can see the support provided from LiveRebel features page.

Question: How does LiveRebel work with changes other than those on the above list?

Answer:

Every time you start the update process LiveRebel will verify the new version for compatibility with the old one. The significant differences will be displayed to you and you can make a decision whether to roll out the update using LiveRebel or conventional server redeploy/restart.

Question: Can I verify the new version for compatibility at build time?

Answer:

Yes, you can. We provide a Maven plugin and an ANT task that you can use to compare your version to some arbitrary version (version in production, staging etc.).

Question: How to verify the new version for compatibility with the old one using Maven?

Answer:

LiveRebel Diff Maven Plugin compares the new archive just built with a specified old one.

To use it add the following fragments to your pom.xml:

<repositories>
...
  <repository>
    <id>zt-repo</id>
    <url>http://repos.zeroturnaround.com/nexus/content/groups/zt-public/</url>
    <releases>
      <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
  </repository>
...
</repositories>
 
<plugins>
...
  <plugin>
    <groupId>com.zeroturnaround</groupId>
    <artifactId>lr-diff-maven</artifactId>
    <executions>
      <execution>
        <id>compare</id>
        <phase>verify</phase>
        <goals>
          <goal>compare</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <compareWith>/path/to/old-version.jar</compareWith>
    </configuration>
  </plugin>
...
</plugins>

Just point the to the archive of the old version.
Notice that both the current archive and the old version must contain valid liverebel.xml files.

By default the comparison results will be printed to the standard output.
To redirect it to a file add my-diff.log under the .

Question: How to verify the new version for compatibility with the old one using Ant?

Answer:

LiveRebel Diff Ant Task compares two archives with each other.

The task is bundled with LiveRebel distribution (lib/lr-diff-ant.jar).
To use it add the following fragment to your build.xml:

<taskdef name="compare" classname="com.zeroturnaround.liverebel.diffant.CompareTask">
  <classpath>
    <pathelement location="/path/to/lr-diff-ant.jar" />
  </classpath>
</taskdef>
 
<compare file="/path/to/new-version.jar" with="/path/to/old-version.jar" />

Notice that both archives must contain valid liverebel.xml files.

By default the comparsion results will be printed to the standard output.
To redirect it to a file add output="my-diff.log" parameter.

Question: How do I update an application?

Answer:

To update the application you need to go through the following steps:

  1. Build the application archive (WAR or EAR) of the new version. It has to include a liverebel.xml with the version of the application. NOTE: this step is not necessary if you are downgrading the application to a previously updated version.
  2. Upload the application archive to LiveRebel Command Center. NOTE: this step is not necessary if you are downgrading the application to a previously updated version.
  3. Select the version you want to switch to and press “Prepare update”. LiveRebel will compare this version to the one currently active and display all incompatibilities and warnings.
  4. Review the version compatibility and press “Update”. LiveRebel Command Center will send the update out to all managed servers. Once all uploads are complete the update will be activated. LiveRebel will pause incoming requests and wait until all requests in-progress complete before activating the update and resuming the new requests. If you also selected the Pause option, LiveRebel will pause all new requests until you press Resume, allowing you to run database or environment updates while user requests are paused.

Although the instructions are given for the Command Center Web UI, the same steps are possible using our CLI utility and REST API.

Question: What happens when I press Update?

Answer:

Behind the scenes LiveRebel will calculate what classes and resources have been changed and upload the application archive to all of the servers along with list of changes. When successful upload to all servers is confirmed, the activation phase begins. The resources are just overwritten on disk, whereas the changed classes are updated one by one. Since LiveRebel sends the list of changes, the agent does not need to scan for updated classes.

Question: How are classes updated?

Answer:

Our proprietary JVM agent versions each class individually, without the need for creating new classloaders. The only extra memory needed for the update is the PermGen used to load the updated classes. This will not cause an OutOfMemoryError that is common when redeploying the applications.

Question: How does LiveRebel work in a cluster?

Answer:

LiveRebel manages as many servers as necessary. If the same application is deployed across many servers, they will be associated with that application in the Command Center. So when updating that application all the servers will be updated at the same time.

Question: How does LiveRebel affect performance?

Answer:

LiveRebel runtime performance overhead is under 3%, as measured by SpecJVM2008. The tests were run on an Amazon Large Instance (7.5 GB memory, 4 EC2 Compute Units, 64-bit platform, I/O Performance: High). For running the tests with LiveRebel lr-agent.jar was enabled and a liverebel.xml file was added to the SPECjvm2008.jar.

SPECjvm2008 Results

Question: How do I rollback an update?

Answer:

From the LiveRebel perspective there is no difference between an update and a rollback, it’s just a version change. Just go through the usual version update process and select the version you want to roll back to.

Question: I have a bunch of third-party JARs, will LiveRebel manage them too?

Answer:

LiveRebel only manages JARs if they have a liverebel.xml file in them.

Question: How is LiveRebel licensed?

Answer:

LiveRebel comes with an evaluation licenses that is valid for 90 days and works for 2 nodes. LiveRebel commercial licenses are sold as annual licenses per JVM instance. There is more information on licensing differences and pricing at http://www.zeroturnaround.com/liverebel/pricing/

Question: If we stop our JEE container, disable LiveRebel and start the server, what will happen to the application version?

Answer:

If you disable LiveRebel and restart the server then the server will pick up the latest version that it can find in its deploy folder. This might not be the latest version activated with LiveRebel! Be sure to update the version of your application to the latest version when restarting the server without LiveRebel.

Question: If we stop our JEE container, disable LiveRebel and deploy our application with usual means and start the server, what will happen to the application version?

Answer:

If you are starting the server without LiveRebel then your JEE container will deploy the version that it finds from it’s deploy folder or equivalent. As liverebel agent is disabled then there is no liverebel.xml parsing present and the file can be deleted from the archive.

Question: If we stop our JEE container, deploy our application with usual means and start the server, what will happen to the application version and what should I look out for?

Answer:

If you are starting the server with LiveRebel and you have updated the application then you need to increase (just change to something new) the version number in liverebel.xml. This ensures that the new manually deployed version is used. LiveRebel Command Center will pick this new version up and it will also show up in the Command Center.

If you did not change the version number of the new archive LiveRebel detects the change but cannot distinguish two versions in the Command Center as the version number is still the same. You will see a message in the standard output of your container,

LiveRebel: Could not manage versions of Your-Application (/../webapps/your-application):
Deployed application is changed without updating the version (1.0).
Please update the version in deployed liverebel.xml and redeploy.

The new version will be used but LiveRebel remains disabled for this application. There is a message in the LiveRebel Command Center also. You need to update the version number and redeploy the application. After that the new version will be picked up by LiveRebel and it will show up in the Command Center.

Question: How to install Tomcat with LiveRebel enabled as Windows service?

Answer:

We assume that you have downloaded and unpacked Tomcat’s Windows package. Tomcat download page knows them under the names of “32-bit Windows zip” or “64-bit Windows zip”. You can verify if you have necessary package installed by existence of the %CATALINA_HOME%\bin\service.bat file.

Now you have a correct installation of the Tomcat. To install Tomcat with LiveRebel as a service, you need to download lr-agent-installer.jar from your LiveRebel Command Center and run it in your %CATALINA_HOME%. It will create a %CATALINA_HOME%\lr-agent directory and configure Tomcat to run with LiveRebel.

Start Command Prompt (cmd.exe) as an administrator (right-click -> Run as Administrator) and navigate to %CATALINA_HOME%\lr-agent directory.

Now to install Tomcat with LiveRebel as Windows service run:
bin\service.cmd install [optional_service_name], where [optional_service_name] is the name for your service (default is “tomcat” + version number, e.g. “tomcat6″ in case of Tomcat 6.x).

Also, if you want to remove a service, run:
bin\service.cmd remove service_name, where service name is a name of the service to remove.

You can start and stop this service from Windows SCM (Service Control Manager). Service startup type is “auto”, which means it will start when Windows starts.

Question: How to install LiveRebel Command Center as Windows service?

Answer:

Use the %LIVEREBEL_HOME%/bin/lr-as-service.cmd script that can install and remove Windows Services.

To install the service run (with the admin rights):
%LIVEREBEL_HOME%/bin/lr-as-service.cmd install [service_name]
where [service_name] is the desired service name.

Also, if you have 64 bit OS and want to use 32 bit java, specify the 32bit flag, as in:
%LIVEREBEL_HOME%/bin/lr-as-service.cmd 32bit install [service_name]

To remove the service run (also with the admin rights):
%LIVEREBEL_HOME%/bin/lr-as-service.cmd uninstall [service_name]

Join the Rebellion Facebook Twitter RSS feed