# begin: following section is used for docu generation - Jagger properties

# ****************************************************************** #
# Main user properties                                               #
# ****************************************************************** #

# # # Selection of test session # # #
# Id of Jagger test load scenario that will be executed
# Load scenarios must be declared as beans.
# There are could be many load scenarios but only single one can be executed during single Jagger run
jagger.load.scenario.id.to.execute=productsResource_ExpandReviews

# ****************************************************************** #
# Data base setup for results storage                                #
# ****************************************************************** #

# # # Setup of MySQL data base for result storage # # #
# If you would like to store results of your test run and later view them in WebUI it is necessary to
# create data storage for results. We recommend to use MySQL DB for this purpose
# In distributed mode DB settings should be added to each Node
# Settings:
# - Driver to access MySQL database
# - Address of MySQL database
#     URL contains host name, port (3306 - default port for MySQL) and schema name
#     You need to create schema in data base before starting Jagger
#     All required tables in schema will be created during test run
# - User name to access MySQL database
# - Password to access MySQL database
# - Hibernate dialect for MySQL access
#     Jagger is using Hibernate to store objects in DB. Uncomment dialect property below to enable
#     proper Hibernate functionality
#
# NOTE:
# - Default MySQL settings below corrspond to the MySQL docker container that is the part of Jagger distribution
# - If you would like to run your project without configuring DB, use H2 data base setting below

chassis.storage.rdb.client.driver=com.mysql.jdbc.Driver
chassis.storage.rdb.client.url=jdbc:mysql://__MYSQL_DB_IP__:3306/jagger_ci_db
chassis.storage.rdb.username=jaggeruser
chassis.storage.rdb.password=jaggerpass
chassis.storage.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect


# # # Setup of H2 data base for result storage # # #
# If you would like to store results of your test run and later view them in WebUI it is necessary to
# create data storage for results
# In distributed mode DB settings should be added to each Node
# Settings:
# - Driver to access H2 database
# - Address of H2 database
#     URL contains host name, port (8043 - default port for H2) and schema name
# - User name to access H2 database
# - Password to access H2 database
# - Hibernate dialect for H2 access
#     Jagger is using Hibernate to store objects in DB. Uncomment dialect property below to enable
#     proper Hibernate functionality

#chassis.storage.rdb.client.driver=org.h2.Driver
#chassis.storage.rdb.client.url=jdbc:h2:file:./jaggerdb
#chassis.storage.rdb.username=jagger
#chassis.storage.rdb.password=rocks
#chassis.storage.hibernate.dialect=org.hibernate.dialect.H2Dialect


# # # Hibernate batch size setup # # #
# Jagger is using Hibernate to store objects in DB (H2 and MySQL are currently supported)
# Batch size - number of values inserted by Hibernate in DB with single SQL command
# If batch size too small - result saving will be very slow
# If batch size too high - large amount of memory will be used for buffering
# Don't change default setup without need

chassis.storage.hibernate.batch_size=50


# ****************************************************************** #
# Monitoring                                                         #
# ****************************************************************** #

# # # Enable monitoring # # #
# Set true to enable monitoring of SUT parameters like CPU utilization, Memory usage, Network load, etc
# See docu for full list of monitored parameters
# When set to true, Jagger will wait for connections with monitoring agent(s) during start up

chassis.conditions.monitoring.enable=false

# # # Number of monitoring agents # # #
# Set number of monitoring agents Jagger should wait for during start up
# Monitoring agents are started to collect information about SUT (like CPU utilization, memory usage, etc)
# Note, that Jagger will wait for agents only when chassis.conditions.monitoring.enable=true

chassis.conditions.min.agents.count=0

# # # Monitoring polling interval, milliseconds # # #
# Interval specifies how often monitoring agent will send data to kernel

chassis.monitoring.pollinginterval=2000

# # # Monitoring profile polling interval, milliseconds # # #
# Interval specifies how often monitoring agent will collect information from SUT

chassis.monitoring.profile.pollinginterval=2000

# # # Timeout setup fot monitoring agent, milliseconds # # #
# Following timeout will be used by monitoring agent during such operations like (information collection,
# communication with kernel during starting / stopping of monitoring, transferring data). If any of
# mentioned operations will exceed specified time, timeout exception will be thrown

chassis.monitoring.command.execution.ttl=30000

# # # Thread pool for communication with monitoring agents # # #
# Settings for thread pool responsible for communication with agents
# Every agent will require at least one thread
# core - number of threads to keep in the pool, even if they are idle.
# max - maximum number of threads allowed in the pool.

#chassis.monitoring.executor.pool.core=2
#chassis.monitoring.executor.pool.max=10

# begin: following section is used for docu generation - Monitoring metrics ids

# # # Setup for monitoring metrics # # #
# Following settings are available for monitoring metrics
# plotData - set true if you want to save metric vs time for plots
# showSummary - set true if you want to save value for summary table
# normalizationBy - possibility to normaliza metric vs time (possible values: NONE, SECOND, MINUTE, HOUR)
#
# if both plotData and saveSummary are false, monitoring metric will be not saved
#
# Below is example for single parameter.
# In the same way you can change setup for following monitoring metrics:
# mon_mem_ram, mon_mem_total, mon_mem_used, mon_mem_actual_used, mon_mem_free_prcnt, mon_mem_actual_free,
# mon_mem_free, mon_tcp_est, mon_tcp_listen, mon_sync_received, mon_inbound_total, mon_outbound_total,
# mon_disk_read_bytes, mon_disk_write_bytes, mon_disk_service_time, mon_disk_queue_size_total, mon_cpu_user,
# mon_cpu_sys_prcnt, mon_cpu_idle_prcnt, mon_cpu_wait, mon_cpu_combined, mon_cpula_1, mon_cpula_5,
# mon_cpula_15, mon_gc_minor_time, mon_gc_minor_unit, mon_gc_major_time, mon_gc_major_unit, mon_heap_init,
# mon_heap_used, mon_heap_committed, mon_heap_max, mon_nonheap_init, mon_nonheap_used, mon_nonheap_committed,
# mon_nonheap_max, mon_thread_count, mon_thread_peak_count
#
# Default setting and short description for all monitoring metrics are available in docu

#chassis.monitoring.mon_cpu_idle_prcnt.plotData=true
#chassis.monitoring.mon_cpu_idle_prcnt.showSummary=false
#chassis.monitoring.mon_cpu_idle_prcnt.normalizationBy=NONE

# end: following section is used for docu generation - Monitoring metrics ids


# ****************************************************************** #
# Session comparison                                                 #
# ****************************************************************** #

# Note: In docu there is separate chapter dedicated to result comparison and decision making

# begin: following section is used for docu generation - Decision making by limits main

# # # Baseline session Id # # #
# Baseline session ID for session comparison.
# By default this value is set to '#IDENTITY' => session will be compared with itself (for testing purposes). Comparison will always pass
# If you would like to compare with some previous run, set this property equal to baseline session Id (f.e. 115)
# Comparison will only work if test data is stored in DB

chassis.engine.e1.reporting.session.comparison.baseline.session.id=#IDENTITY

# end: following section is used for docu generation - Decision making by limits main
# begin: following section is used for docu generation - Decision making by limits aux

# # # Decision when no matching metric for limit is found # # #
# Valid when you are using decision making with limits
# Describes: What decision should be taken when limit is specified, but no metric in the test matches metricName of this Limit
# Default: OK - because this is not critical (you can specify limits in advance - it doen't influence quality of results)
# Allowed values (Decision enum): OK, WARNING, ERROR, FATAL
chassis.decision.maker.with.limits.decisionWhenNoMetricForLimit=OK

# # # Decision when no baseline value is found for metric # # #
# Valid when you are using decision making with limits
# Describes: What decision should be taken when baseline value can't be fetched for some metric (f.e. test or metric doesn't exist in baseline session)
# Default: FATAL - because we can not compare results to baseline => we can not take decision
# Allowed values (Decision enum): OK, WARNING, ERROR, FATAL
chassis.decision.maker.with.limits.decisionWhenNoBaselineForMetric=FATAL

# # # Decision when several limits match single metric # # #
# Valid when you are using decision making with limits
# Describes: What decision should be taken when several limits match same metric (f.e. 'mon_cpu' & 'mon_cpu_user' will match 'mon_cpu_user|agent_007 [127.0.1.1]|-avg')
# Default: FATAL - because in this case we will have several decisions (equal to number of matching limits) => we can not decide what decision should be saved for this metric
# Allowed values (Decision enum): OK, WARNING, ERROR, FATAL
chassis.decision.maker.with.limits.decisionWhenSeveralLimitsMatchSingleMetric=FATAL

# end: following section is used for docu generation - Decision making by limits aux

# begin: following section is used for docu generation - Properties files and hierarchy
# ****************************************************************** #
# Other property files                                              #
# ****************************************************************** #

# # # Path to file with default properties # # #
# Properties hierarhy:
# Default properties -> Environment properties -> User properties -> System properties [higher priority]
jagger.default.environment.properties=./configuration/basic/default.environment.properties

# # # Comma separated list of paths to files with user properties # # #
# You can use multiple property files f.e. for different environment configurations
# or for different tests
# Properties hierarhy:
# Default properties -> Environment properties -> User properties -> System properties [higher priority]
#jagger.user.environment.properties=./profile/basic/test_config1.properties,./profile/basic/sut_config.properties

# end: following section is used for docu generation - Properties files and hierarchy


# ****************************************************************** #
# Stand by mode properties                                           #
# ****************************************************************** #

# Launchers Jagger in stand by mode.
# When Jagger is up and running but does not execute any test.
# But rather communicates with JaaS and waits when and which test to execute.
realtime.enable.standby.mode=false

# # # Below set of properties takes effect only when realtime.enable.standby.mode=true # # #
# Unique name for the env.
# If an env with such a name already exists will be assigned dynamically generated name.
realtime.environment.id=jagger-default-test-env
# URL to JaaS
realtime.jaas.endpoint=http://localhost:8088/jaas
# How often status will be reported
realtime.status.report.interval.seconds=15


# ****************************************************************** #
# Timeouts                                                           #
# ****************************************************************** #

# # # Workload timeouts # # #

# Timeout for master to start workload and monitoring distributors
#chassis.master.distribution.start=300000

# Timeout for master to stop workload and monitoring  distributors
#chassis.master.distribution.stop=300000

# Timeout for distributor to start all tasks (workload tests, monitoring)
workload.start.timeout=120000

# Timeout for distributor to stop all tasks (workload tests, monitoring)
#workload.stop.timeout=3600000

# Timeout for distributor to change workload configuration
#workload.polling.timeout=30000

# Max duration of workload
# 5 years = 157680000000
#chassis.master.task.maxtime=157680000000


# # # Connection timeouts # # #

# Time which master waits for Agents, Kernels. During this period all nodes should register by master.
# 10 min = 600000
#chassis.master.node.awaittime=600000


# ****************************************************************** #
# Reporting                                                          #
# ****************************************************************** #

# # # Session comment # # #
# You can put session comment here. It will go to PDF report and WebUI
# More flexible way to save session comments - use SessionInfoService which allows to save comments at run time

report.session.comment=

# begin: following section is used for docu generation - Aggregation interval

# # # Number of points displayed in plots # # #
# Properties will influence aggregation interval of measured parameters
# You can define exact interval between points,
#   or you can define count of points and interval will be calculated
# It is also possible to set interval or point count for every measured parameter separatly
# See Aggregators documentation for more info

chassis.engine.e1.reporting.task.type=count
# chassis.engine.e1.reporting.task.type=interval

# Exact interval between plot points in milliseconds

chassis.engine.e1.reporting.task.point.interval=5000

# Count of points

chassis.engine.e1.reporting.task.point.count=100

# end: following section is used for docu generation - Aggregation interval

# # # Default report format (PDF or HTML) # # #

chassis.master.reporting.report.format=PDF

# # # Default report file name # # #

chassis.master.reporting.report.file.name=report.pdf

# # # Flag to enable fetching decisions per metric from DB and highlighting it in UI # # #

report.enable.decisions.per.metric.highlighting=true

# # # Location of root report template (Spring resource location format) # # #

#chassis.master.reporting.root.report.template.location=configuration/reporting/report-container.jrxml

# # # Settings to run Jagger in reporter mode # # #
# To run Jagger in reporter mode and create PDF report execute:
#   ./start.sh ./profiles/basic/environment.properties -Dchassis.roles=REPORTER
# where environment.properties - this file

# Set true if you are generating report with 'chassis.roles=REPORTER'
# IMPORTANT: if you will set this property during test run, you will currupt
# data for session with id 'report.session.id'
# Be careful
#report.only=true

# Generate report for session with this Id
#report.session.id=106

# Set session name for report. Will be displayed on first page
#report.session.name=J4G session sample


# ****************************************************************** #
# Single node / Distributed mode                                     #
# ****************************************************************** #

# # # Jagger roles # # #
# Use default value. In most cases it will fit requirements
# As short emplanation of roles: if you will launch Jagger with REPORTER role,
# it will just compile report without generating any load
# More info about roles you can get in docu
# Comma-separated list of roles. When Jagger starts the corresponding services are launched
# MASTER,KERNEL,COORDINATION_SERVER,RDB_SERVER,REPORTER
#chassis.roles=MASTER
#chassis.roles=RDB_SERVER
#chassis.roles=COORDINATION_SERVER
#chassis.roles=MASTER,COORDINATION_SERVER,RDB_SERVER
#chassis.roles=KERNEL

chassis.roles=MASTER,KERNEL,COORDINATION_SERVER,RDB_SERVER,HTTP_COORDINATION_SERVER

# # # Coordination setup # # #
# chassis.coordination.bean is bean name that implements Coordinator interface.
# memoryCoordinator (local mode only) - single load node is playing all Jagger roles
# zookeeperCoordinator - distributed load nodes can play different roles
#chassis.coordination.bean=zookeeperCoordinator

chassis.coordination.bean=memoryCoordinator

# # # Storage setup # # #
# chassis.log.storage.bean is bean name that implements FileStorage interface.
# localFileStorage (local mode only) - when single load node is used
# hdfsStorage - for distributes load
chassis.log.storage.bean=hdfsStorage

#chassis.log.storage.bean=localFileStorage

# # # Zookeeper # # #
# Address and port of ZooKeeper Server
# Should be detemined on each Node in distributed mode . 2181 default port
#chassis.coordinator.zookeeper.endpoint=172.56.45.222:2181

# ZooKeeper session timeout

chassis.coordinator.zookeeper.session.timeout=100000000

# Path of zookeeper

chassis.coordinator.zookeeper.root.node=/root-001

# # # Thread pool for zookeeper communication # # #
# Settings for thread pool responsible for communication with nodes in zookeeper configuration
# core - number of threads to keep in the pool, even if they are idle.
# max - maximum number of threads allowed in the pool.
#chassis.zookeeper.executor.pool.core=2
#chassis.zookeeper.executor.pool.max=30

# Address and port of HDFS, MASTER
# Should be determined on each Node in distributed mode
#chassis.storage.fs.default.name=hdfs://172.56.45.222/

# # # Coordinator # # #
# Coordinator port
# Http Server starts with that port on HTTP_COORDINATION_SERVER, 8089 - default
#chassis.coordination.http.port=8089

# Reconnect period of MASTER/KERNEL to COORDINATIONA_SERVER
#chassis.coordinator.reconnect.period=5000

# Minimum number of kernels expected by master

chassis.conditions.min.kernels.count=1

# # # Thread pool for workload execution / agent execution # # #
# Property is defining size of thread pool for two different and independent components:
# 1. Execution of workload. Threads for workload task execution, monitoring, etc
# Threads producing load are not influenced by this property
# 2. Running of agent. Threads for agent results collection and posting to coordinator
# core - number of threads to keep in the pool, even if they are idle.
# max - maximum number of threads allowed in the pool.
#chassis.executor.pool.core=5
#chassis.executor.pool.max=20

# # # Workload threads # # #
# Max allowed threads during workload generation
#workload.threads.maxcount=4000

# # # Serialization # # #
# If true, jBoss serealisation will be used for communication between all nodes

chassis.util.usejboss=true

# ****************************************************************** #
# Other properties                                                   #
# ****************************************************************** #


# Use java builders to generate configuration instead of schema based approach
chassis.master.using.builders=true

# User package which to scan for user specified Spring configurations when java builders are used
chassis.master.package.to.scan=com.macys.platform

# Default HTTP invoker configurations
chassis.default.invoker.max.connections.total=2147483647
chassis.default.invoker.max.connections.route=2147483647
chassis.default.invoker.connect.timeout.in.milliseconds=60000

# How often status of execution will be printed to screen
#chassis.logging.period=2000

# Size of buffer used for logging
#chassis.log.storage.buffer.flushing.size=1000

# Workspace for localFileStorage
#chassis.log.storage.file.workspace=${chassis.workspace}/storage

# Absolute or relative path to Jagger workspace. Jagger uses this folder to store its files
#chassis.workspace=./jaggerworkspace

# Log out extentions info
#chassis.extensions.log.extensions=true

# Hadoop start properties
#hadoop.tmp.dir=${chassis.workspace}/master/storage/tmp
#hadoop.log.dir=${chassis.workspace}/master/storage/log
#hadoop.home.dir=${chassis.workspace}/master/storage/home
#hadoop.id.str=jagger
#dfs.name.dir=${chassis.workspace}/master/storage/hdfs/namedir
#fs.default.name=${chassis.storage.fs.default.name}
#dfs.replication=1
#dfs.support.append=true

# end: following section is used for docu generation - Jagger properties


# begin: following section is used for docu generation - How to enable summary calculation for monitoring metrics

# Uncomment following lines to enable summary value calculation for some of monitoring metrics
#chassis.monitoring.mon_cpula_1.showSummary=true
#chassis.monitoring.mon_cpula_5.showSummary=true
#chassis.monitoring.mon_cpula_15.showSummary=true
#chassis.monitoring.mon_cpu_user.showSummary=true
#chassis.monitoring.mon_gc_minor_unit.showSummary=true
#chassis.monitoring.mon_gc_minor_time.showSummary=true
#chassis.monitoring.mon_gc_major_unit.showSummary=true
#chassis.monitoring.mon_gc_major_time.showSummary=true


# end: following section is used for docu generation - How to enable summary calculation for monitoring metrics