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/
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.
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.
If servers see the Command Center only through the proxy, then Command Center’s address used for the LiveRebel Agents must be configured from the Configuration tab. After changing address of Command Center, the new address must be also propagated to all LiveRebel Agents. To achieve this either reinstall LiveRebel Agent on each server or update lr-agent/conf/lr-agent.properties files manually on the servers.
Some proxy servers may limit the size of file uploads. Make sure this limit is enough for the application archives transfered between Command Center and the Agents.
If you want to bind on a custom path, 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”, then you can access it via https://yourhost.com/my-very-own-path.
LiveRebel handles all changes to resources (.css, .html, .js, .jsp, etc) and the majority of changes to classes (excluding changes to type hierarchy). LiveRebel preserves all application state, but does not create new state.
The following type of changes to classes are unsupported:
Because LiveRebel cannot create new state the following types of changes may have undesired effect:
However LiveRebel does support new static fields and changes to enums.
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 lazily updated one by one once they get reinvoked. 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.
Due to the increase of PermGen consumption a server may fail with the error “OutOfMemoryError: PermGen”. In that case please increase the PermGen size by using the -XX:MaxPermSize Java option.
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.
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.
Yes, you can use a load balancer for the servers. 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:
If load balancer is configured to serve lr-demo application from both tomcat servers using url
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/
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 part of your cluster at one time (the percentage depends on the session propagation mechanism, most stable would be to update servers one-by-one) with the offline restart strategy, so the other part can handle the requests from users.
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, in case it was updated using hotpatching! Be sure to update the version of your application to the latest version when restarting the server without LiveRebel.
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.
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 does not detect that the application was changed. The old version remains still active as it’s served from LiveRebel’s own work directory.
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.