Jaspersoft for AWS Troubleshooting

Updating a BYOL License

An initial Jaspersoft BYOL deployment has a license that is valid for 3 days.

You can get a trial license through working with TIBCO Jaspersoft sales, or emailing eval@jaspersoft.com

BYOL production licenese are delivered when a Jaspersoft subscription is purchased or renewed.

Server licenses are not needed for Jaspersoft Hourly instances!

To update the license for single BYOL instances, the jasperserver.license key needs to be put on the JasperReports Server instance.

  • SFTP into the instance (like SSHing in below)
  • copy the jasperserver.license file into the ec2-user home directory
  • SSH into the instance
  • sudo cp jasperserver.license /usr/share/tomcat8/webapps/jasperserver-pro/WEB-INF
  • sudo service tomcat8 restart

To update the license for BYOL cluster deployments:

  • drop your "jasperserver.license" key file into the S3 bucket created by the Stack
  • terminate any running instances
  • the instances now started by the Auto Scaling group will pick up the new license file from the S3 bucket

Getting into a JasperReports Server instance via SSH

Now we will want to SSH into the detached instance and look at logs:

  • Change the security group the instance is using to allow SSH into it for the IPs and/or security groups you are are going to SSH in from
    • Because of private subnets, you may need to use a bastion to get into the network being used by the instances
  • Using the key from the Key Pair you selected when you created the Stack, SSH into the instance as "ec2-user"

JasperReports Server log files on instances launched from an AMI

You can get the System Log of the instance through the AWS Console.

After SSHing into an instance, look at files in the /var/log directory

  • cfn-init-cmd.log
  • cfn-init.log
  • jasperserver/jasperserver.log
  • (sudo) /var/log/tomcat8/catalina.out

Problem: JasperReports Server instances in a cluster are repeatedly terminated and relaunched


Behavior 1:

  • Using the load balancer domain http://<load balancer domain>, you can reach a JasperReports Server home page
  • Trying the Login button on the home page, JasperReports Server is not available - 404 error: can't get to login screen at http://<load balancer domain>/jasperserver-pro
  • Retrying, you may get Behavior 2 (below): can't reach the home page, or the 404 again

What is happening?

A JasperReports Server instance has started in the cluster (Auto Scaling Group). On that instance:

  • The Tomcat web server is running - so you see the home page
  • The JasperReports Server app within Tomcat has not started successfully

Behavior 2:

  • Using the load balancer domain http://<load balancer domain>, you get "504 Gateway Time-out"

What is happening?

A JasperReports Server instance has started in the cluster (Auto Scaling Group). The Tomcat web server did not start on that instance.

Finding the problem

With both behaviors:

  • The Auto Scaling Group has a Health Check that tries to reach the login page.
  • If the Health Check repeatedly fails, the instance will be marked as bad, terminated and a new instance started.
  • Looking at the Auto Scaling Group Activity History, you see this "start, then terminate" cycle

To see what is happening on the instance, we need to get a running instance that is not going to be terminated:

  • Go into the Auto Scaling Group, Instances tab
  • Select the running instance - box is highlighted
  • Hit the Actions button > Detach
  • Hit Detach Instance on the dialog box

If you want to stop the terminate/restart cycle while this is being fixed, change the Min and Desired number of instances on the Auto Scaling Group to 0. You can change those values back when you are ready.

SSH into the detached instance and inspect the logs (outlined above) for exceptions.

The most likely culprit is a networking related issue where the instance cannot connect to the RDS database. See https://community.jaspersoft.com/wiki/jaspersoft-aws-cloudformation-template-72-byol-cluster-advanced-deployment for advice on VPC/subnet best practices.