LiveView Server System Configuration

< Previous		Next >

One LiveView Fragment Per StreamBase Application

Current architectural limitations prevent having more than one LiveView fragment in the same node. In practical terms, this means do not try to configure a StreamBase Runtime application with more than one LiveView fragment.

Project-Specific Configuration Files

To manage LiveView Server configuration settings, place a HOCON LiveView engine configuration file in the src/main/configurations directory at the root of your Studio project directory and place your settings there. The LiveView engine configuration inherits from the EventFlow engine configuration, which in turn inherits from the base Java engine configuration.

System Logging Overview

For all supported operating systems, StreamBase uses the industry-standard SLF4J logging system with the Logback framework. See Windows Event Logging for additional considerations for Windows.

All subsystems in EventFlow and LiveView fragments use Logback logging. You can configure the level of logging information emitted, and can direct logs to different appenders using standard Logback configuration files in either XML or Groovy formats.

Log files are written by default into a subdirectory named logs in a fragment's node directory:

For fragments run in StreamBase Studio, the node directory is removed on Studio exit for all successful fragment launches. If a launch fails, its node directory is preserved so that you can inspect log files.
For fragment launches made from the command line, you specify the location of each fragment's node directory as part of the epadmin node install command. In this case, the node directory and its logs subdirectory is preserved in the location you specify.

See Using StreamBase Logging for more information regarding logging.

Setting LiveView JVM Heap Memory

When launching a LiveView application from the command line or from StreamBase Studio, you might receive warnings such as:

MemoryConfigTooLow - Maximum heap size configured to be 3,204 MB, 
which is below recommended size for LiveView production configurations

To avoid such warnings, you can increase the maximum JVM heap size for the current LiveView project. Do this the same way for LiveView projects by setting Xmx and Xms values in the jvmArgs property of the LiveView Engine configuration file for your LiveView project. For a JVM heap memory example, see the Hello LiveView sample's engine.conf file, located in src/main/configurations, which provides settings like the following:

jvmArgs = [
  "-Xmx3g"
  "-Xms512m"
  "-XX:+UseG1GC"
  "-XX:MaxGCPauseMillis=500"
  "-XX:ConcGCThreads=1"
]

Settings of -Xmx4g or even -Xmx8g may be more realistic settings for LiveView. Remember that LiveView data tables exist only in heap memory. Be sure to configure the machine or VM that hosts LiveView server to have enough RAM, and be sure to configure enough -Xmx maximum heap memory to contain your expected volume of data passing through your LiveView data tables.

See Java VM Memory Settings for further details.

Setting StreamBase and LiveView Ports

A running LiveView instance uses two ports. Each LiveView instance requires two TCP ports: one for server processes (the StreamBase port) and one for client connections (the LiveView port). By default, these port numbers are 10000 and 11080, respectively. When you start a LiveView project, both ports are in use.

You can set alternative port numbers in one of the following ways for a server process:

For the StreamBase port, set the portNumber property for an EventFlow Client API Listener configuration file:

name = "sbport"
version = "1.0.0"
type = "com.tibco.ep.streambase.configuration.sbclientapilistener"
configuration = {
  ClientAPIListener = {
    apiListenerAddress = {
      portNumber = 10000
    }
  }
}

Set portNumber to zero to specify setting a random available port number.

For the LiveView port, set the portNumber property for an LiveView Client API Listener configuration file:
```
name = "lvport"
type = "com.tibco.ep.ldm.configuration.ldmclientapilistener"
version = "1.0.0"
configuration = {
  ClientAPIListener = {
    portNumber = 11080
  }
}
```
As with the StreamBase port, set the LiveView server's portNumber to zero to specify setting a random available port number.
If you are running from StreamBase Studio, you can edit the ports as follows. These Studio settings can override any configuration file settings for development in Studio. For production deployment, always use configuration files as described above.
1. Run the LiveView fragment at least once in Studio. This creates a run configuration for the project.
2. Right-click the project folder, or on any of the lvconf files for the project, and select Run As>Run Configurations.
3. Select LiveView Fragment and select the run configuration named for the project you just ran.
4. Configure port number settings as desired for the running this project in Studio. The default setting is to honor the port settings in the project's configuration files if present, or to use port 10000 for StreamBase and 11080 for LiveView if not. You can also specify an explicit port, or configure Studio to choose any available port.
5. To run the LiveView project with the new port settings, click Apply, then Run.

Configuring the Location of Generated Files

At runtime, the LiveView server creates a directory named lv-systemdata to contain the SQLite database and a trace debugging database. The SQLite database is LiveView's default method of storing the configuration of alert rules. (See LiveView Metadata Store for alternative ways to store the same information.)

If you are using the default SQLite metadata store, you might need to manage the location of the SQLite database to preserve alert rules.

Running in Studio

When running LiveView fragments or applications in StreamBase Studio, Studio forces the location of the system data, overriding the system property discussed below, if it is configured in the project. The content that would otherwise go into the lv-systemdata directory is automatically redirected to src/main/resources.

This makes the SQLite database visible and easily incorporated into any source control system you are using to manage your LiveView project source files. This feature allows you to preserve any alert rules that were configured while the LiveView server was running in Studio.

This redirection is performed in Studio independent of the setting of the system property described below. This allows you to configure the system property in advance for use when deploying this project with epadmin, but still run the same project in Studio and preserve the SQLite database in source control.

Running on the Command Line

When running a LiveView application from the command line with the epadmin command, you specify the containing location of a node directory for the application as part of the command (or the current directory if unspecified). The node directory itself takes the same name as nodename.clustername. For example, if you specify ‑‑nodedirectory=/home/sbuser/nodedirs and ‑‑nodename=A.X, then the node directory is found in /home/sbuser/nodedirs/A.X.

By default, the lv-systemdata directory is placed in the application/engines location for the LiveView fragment in the application:

node-directory/application/engines/default-engine-for-packageName/lv-systemdata

where packageName is the GroupId plus ArtifactId of the LiveView fragment.

When deploying a LiveView application from the command line, you can specify an alternate location for the lv-systemdata directory by means of the liveview.systemdata.directory system property.

Remember that the node directory is removed from disk when you run an epadmin remove node command. If you leave the SQLite database in its default location, it is lost when the node is removed. Any alert rules you made while the LiveView server was running are lost unless you save these artifacts outside of the node directory.

liveview.systemdata.directory: Specify an alternate location for the contents of the lv-systemdata directory, which is primarily the SQLite database file. Use a full, absolute path or a relative path. Remember that a full path must be valid on any QA, staging, and/or production servers as well as your development machine. Relative paths are relative to the top of the current node directory. Thus, a setting of ../lvdata places the lvdata directory parallel to the node directory, where it will survive the node directory's removal.

System Property Configuration File Example

The configuration file below stores the SQLite and trace database files to a directory named lvdata that will be parallel to the node directory, and will survive the removal of the node directory.

name = "lvengine"
type = "com.tibco.ep.ldm.configuration.ldmengine"
version = "1.0.0"
configuration = {
  LDMEngine = {
    jvmArgs =
      [ "-Xmx4g"
        "-Xms512m"
        "-XX:+UseG1GC"
        "-XX:MaxGCPauseMillis=500"
        "-XX:ConcGCThreads=1"
      ]
    systemProperties = {
      "liveview.systemdata.directory" = "../lvdata"  
    }
  }
}