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/
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.
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.
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.
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:
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.
LiveRebel supports changes to framework/server configuration with plugins. You can see the support provided from LiveRebel features page.
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.
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. 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 half of your cluster at one time (with offline restart strategy), so the other half can handle the requests from users.
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.
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.
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.
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.
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.