Frequently Asked Questions

Question: How is LiveRebel licensed?

Answer: LiveRebel comes with a free license that is valid for one year 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: 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.

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 hotpatching 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 hotpatching work internally?

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.

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 to use edit mode?

With LiveRebel “edit server”, your workflow would be like this: * Start “edit mode” in LiveRebel Command Center GUI, it will tell you the exact file system location of the expanded application.

• Copy changed files to server (JAR and other) (changes are immediately visible to users) - you get exact path from the first step.
• Finish “edit mode” in LiveRebel Command Center GUI, webapp contents are packaged into a new application version ready to be deployed to other servers.

Question: How does the agent communicate with the Command Center? Do I have to open any ports in order to allow the agents to communicate with the command center?

Command Center binds on https port 9001 by default. However you can override that with LIVEREBEL_PORT environment variable or by setting -Dport=10001 system property in JAVA_OPTS for command center process. Agent installed into your application/file/db server sends messages to LRCC:9001 port, so this port must be accessible. Applications are deployed/updated to your application server through the agent. Agent need to “see” Command Center but not vice versa. The other way communication is implemented by polling for tasks.

Question: Can I use LiveRebel with load balancer?

Yes, you can. Keep in mind that LiveRebel Command Center shows you the original URLs of the applications not the URLs accessing the load balancer.

In general LiveRebel doesn’t know and care about the presence of load balancer and vice versa - Load balancer doesn’t know and care about LiveRebel. However, this means that if a load balancer also replaces the port that is used to serve application, then LiveRebel still gives you the url (host, port, context path) that is used by application server to serve requests for the application. Example:

You have two tomcats running on port 8080 and serving application with context path “lr-demo”. This means that tomcat servers accepts requests for that application from following urls:

http://hostOfTomcat1:8080/lr-demo/
http://hostOfTomcat2:8080/lr-demo/

If load balancer is configured to serve lr-demo application from both tomcat servers using url

http://myApplicationHost/lr-demo/

then for lr-demo application and tomcat1 server LiveRebel gives you the link http://hostOfTomcat1:8080/lr-demo/ that may be not publically accessible. So LiveRebel doesn’t know that the application deployed to both tomcat servers are publically available from port 80 of the host used by load balancer: http://myApplicationHost/lr-demo/

Question: Is LiveRebel compatible with clustered session persistence frameworks?

LiveRebel does not interfere with session persistence frameworks; you can freely use them in combination. When using session persistence, you most probably will want to update half of your cluster at one time (with offline restart strategy), so the other half can handle the requests from users.

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 its 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: Why does CC use self-signed certificate?

We would have had purchased properly-signed HTTPS certificate if it would work in all customer environments - unfortunately, it is not that simple. HTTPS certificates are tied to specific domain names and we have no control over the final domain name where LiveRebel Command Center GUI will be available (in customer environment). Very often there is not even a domain name, just an IP address. This means that it is impossible for us to ship a single certificate that would work in all environments. Although we cannot use a properly signed certificate, we still would like to encrypt the communication between LiveRebel Command Center and user browser. So we chose to use a self-signed certificate for this.

Question: What is the advantage of LiveRebel Rolling Restart in comparison to session replication in Tomcat + load balancer?

• Session-Replication only works when session isn’t changed enough that it can’t be Serialized/Deserialized anymore. Such situation is fairly common and in that case users will lose the session. LiveRebel will wait until the session expires to migrate the users.
• If you do not restart each server during an update you will get memory leaks and eventually OutOfMemoryError. Restarting the servers during an update means that you rely on scripting that isn’t recoverable on failure.
• More importantly, LiveRebel will always deliver your update to production in the cheapest way possible and can choose the best strategy for you (e.g. through lr-cli.sh or CI server plugins). It always leaves the system in a consistent state and always provides you with a rollback switch. It is about the ability to roll updates during the day, multiple times a day in absolute surety that user impact will be minimal to none even in case of failure or breaking change. It’s not about the features, it’s about the experience :)

Question: How to backup LiveRebel data and settings?

On Command Center side, you should backup the data directory; on server side, you should back up lr-agent/data and lr-agent/conf directories for full recovery.