2014-01-06 15:58:46 -05:00
|
|
|
##################### Elasticsearch Configuration Example #####################
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# This file contains an overview of various configuration settings,
|
|
|
|
# targeted at operations staff. Application developers should
|
|
|
|
# consult the guide at <http://elasticsearch.org/guide>.
|
|
|
|
#
|
|
|
|
# The installation procedure is covered at
|
2013-10-09 06:15:24 -04:00
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/setup.html>.
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-01-06 15:58:46 -05:00
|
|
|
# Elasticsearch comes with reasonable defaults for most settings,
|
2011-09-22 09:44:12 -04:00
|
|
|
# so you can try it out without bothering with configuration.
|
|
|
|
#
|
|
|
|
# Most of the time, these defaults are just fine for running a production
|
|
|
|
# cluster. If you're fine-tuning your cluster, or wondering about the
|
|
|
|
# effect of certain configuration option, please _do ask_ on the
|
|
|
|
# mailing list or IRC channel [http://elasticsearch.org/community].
|
|
|
|
|
2011-09-26 14:30:18 -04:00
|
|
|
# Any element in the configuration can be replaced with environment variables
|
|
|
|
# by placing them in ${...} notation. For example:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.rack: ${RACK_ENV_VAR}
|
2011-09-26 14:30:18 -04:00
|
|
|
|
2013-10-09 06:15:24 -04:00
|
|
|
# For information on supported formats and syntax for the config file, see
|
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/setup-configuration.html>
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
################################### Cluster ###################################
|
|
|
|
|
|
|
|
# Cluster name identifies your cluster for auto-discovery. If you're running
|
|
|
|
# multiple clusters on the same network, make sure you're using unique names.
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#cluster.name: elasticsearch
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
#################################### Node #####################################
|
|
|
|
|
|
|
|
# Node names are generated dynamically on startup, so you're relieved
|
|
|
|
# from configuring them manually. You can tie this node to a specific name:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.name: "Franz Kafka"
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Every node can be configured to allow or deny being eligible as the master,
|
|
|
|
# and to allow or deny to store the data.
|
|
|
|
#
|
|
|
|
# Allow this node to be eligible as a master node (enabled by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.master: true
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
|
|
|
# Allow this node to store data (enabled by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.data: true
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# You can exploit these settings to design advanced cluster topologies.
|
|
|
|
#
|
|
|
|
# 1. You want this node to never become a master node, only to hold data.
|
|
|
|
# This will be the "workhorse" of your cluster.
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.master: false
|
|
|
|
#node.data: true
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
|
|
|
# 2. You want this node to only serve as a master: to not store any data and
|
|
|
|
# to have free resources. This will be the "coordinator" of your cluster.
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.master: true
|
|
|
|
#node.data: false
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
|
|
|
# 3. You want this node to be neither master nor data node, but
|
|
|
|
# to act as a "search load balancer" (fetching data from nodes,
|
|
|
|
# aggregating results, etc.)
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.master: false
|
|
|
|
#node.data: false
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Use the Cluster Health API [http://localhost:9200/_cluster/health], the
|
2014-02-06 11:25:12 -05:00
|
|
|
# Node Info API [http://localhost:9200/_nodes] or GUI tools
|
2014-02-06 04:29:16 -05:00
|
|
|
# such as <http://www.elasticsearch.org/overview/marvel/>,
|
|
|
|
# <http://github.com/karmi/elasticsearch-paramedic>,
|
|
|
|
# <http://github.com/lukas-vlcek/bigdesk> and
|
2011-09-22 09:44:12 -04:00
|
|
|
# <http://mobz.github.com/elasticsearch-head> to inspect the cluster state.
|
|
|
|
|
2011-09-26 14:30:18 -04:00
|
|
|
# A node can have generic attributes associated with it, which can later be used
|
|
|
|
# for customized shard allocation filtering, or allocation awareness. An attribute
|
|
|
|
# is a simple key value pair, similar to node.key: value, here is an example:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.rack: rack314
|
2011-09-26 14:30:18 -04:00
|
|
|
|
2012-02-01 06:34:35 -05:00
|
|
|
# By default, multiple nodes are allowed to start from the same installation location
|
|
|
|
# to disable it, set the following:
|
2014-04-17 16:17:51 -04:00
|
|
|
#node.max_local_storage_nodes: 1
|
2012-02-01 06:34:35 -05:00
|
|
|
|
2012-02-17 08:43:53 -05:00
|
|
|
|
2011-09-22 09:44:12 -04:00
|
|
|
#################################### Index ####################################
|
|
|
|
|
|
|
|
# You can set a number of options (such as shard/replica options, mapping
|
|
|
|
# or analyzer definitions, translog settings, ...) for indices globally,
|
|
|
|
# in this file.
|
|
|
|
#
|
|
|
|
# Note, that it makes more sense to configure index settings specifically for
|
|
|
|
# a certain index, either when creating it or by using the index templates API.
|
|
|
|
#
|
2013-10-09 06:15:24 -04:00
|
|
|
# See <http://elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules.html> and
|
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/indices-create-index.html>
|
2011-09-22 09:44:12 -04:00
|
|
|
# for more information.
|
|
|
|
|
|
|
|
# Set the number of shards (splits) of an index (5 by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#index.number_of_shards: 5
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set the number of replicas (additional copies) of an index (1 by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#index.number_of_replicas: 1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Note, that for development on a local machine, with small indices, it usually
|
|
|
|
# makes sense to "disable" the distributed features:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#index.number_of_shards: 1
|
|
|
|
#index.number_of_replicas: 0
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# These settings directly affect the performance of index and search operations
|
|
|
|
# in your cluster. Assuming you have enough machines to hold shards and
|
|
|
|
# replicas, the rule of thumb is:
|
|
|
|
#
|
|
|
|
# 1. Having more *shards* enhances the _indexing_ performance and allows to
|
|
|
|
# _distribute_ a big index across machines.
|
|
|
|
# 2. Having more *replicas* enhances the _search_ performance and improves the
|
|
|
|
# cluster _availability_.
|
|
|
|
#
|
|
|
|
# The "number_of_shards" is a one-time setting for an index.
|
|
|
|
#
|
|
|
|
# The "number_of_replicas" can be increased or decreased anytime,
|
|
|
|
# by using the Index Update Settings API.
|
|
|
|
#
|
2014-01-06 15:58:46 -05:00
|
|
|
# Elasticsearch takes care about load balancing, relocating, gathering the
|
2011-09-22 09:44:12 -04:00
|
|
|
# results from nodes, etc. Experiment with different settings to fine-tune
|
|
|
|
# your setup.
|
|
|
|
|
|
|
|
# Use the Index Status API (<http://localhost:9200/A/_status>) to inspect
|
|
|
|
# the index status.
|
|
|
|
|
|
|
|
|
|
|
|
#################################### Paths ####################################
|
|
|
|
|
|
|
|
# Path to directory containing configuration (this file and logging.yml):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.conf: /path/to/conf
|
2011-09-22 09:44:12 -04:00
|
|
|
|
2011-09-25 14:06:12 -04:00
|
|
|
# Path to directory where to store index data allocated for this node.
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.data: /path/to/data
|
2011-09-25 14:06:12 -04:00
|
|
|
#
|
2011-09-25 15:00:13 -04:00
|
|
|
# Can optionally include more than one location, causing data to be striped across
|
2012-11-09 15:54:17 -05:00
|
|
|
# the locations (a la RAID 0) on a file level, favouring locations with most free
|
2011-09-25 15:00:13 -04:00
|
|
|
# space on creation. For example:
|
2011-09-25 14:06:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.data: /path/to/data1,/path/to/data2
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Path to temporary files:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.work: /path/to/work
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Path to log files:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.logs: /path/to/logs
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Path to where plugins are installed:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#path.plugins: /path/to/plugins
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
2012-02-17 08:43:53 -05:00
|
|
|
#################################### Plugin ###################################
|
|
|
|
|
|
|
|
# If a plugin listed here is not installed for current node, the node will not start.
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#plugin.mandatory: mapper-attachments,lang-groovy
|
2012-02-17 08:43:53 -05:00
|
|
|
|
|
|
|
|
2011-09-22 09:44:12 -04:00
|
|
|
################################### Memory ####################################
|
|
|
|
|
2014-01-06 15:58:46 -05:00
|
|
|
# Elasticsearch performs poorly when JVM starts swapping: you should ensure that
|
2011-09-22 09:44:12 -04:00
|
|
|
# it _never_ swaps.
|
|
|
|
#
|
|
|
|
# Set this property to true to lock the memory:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#bootstrap.mlockall: true
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Make sure that the ES_MIN_MEM and ES_MAX_MEM environment variables are set
|
|
|
|
# to the same value, and that the machine has enough memory to allocate
|
2014-01-06 15:58:46 -05:00
|
|
|
# for Elasticsearch, leaving enough memory for the operating system itself.
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-01-06 15:58:46 -05:00
|
|
|
# You should also make sure that the Elasticsearch process is allowed to lock
|
2011-09-22 09:44:12 -04:00
|
|
|
# the memory, eg. by using `ulimit -l unlimited`.
|
|
|
|
|
|
|
|
|
|
|
|
############################## Network And HTTP ###############################
|
|
|
|
|
2014-01-06 15:58:46 -05:00
|
|
|
# Elasticsearch, by default, binds itself to the 0.0.0.0 address, and listens
|
2011-09-26 14:32:46 -04:00
|
|
|
# on port [9200-9300] for HTTP traffic and on port [9300-9400] for node-to-node
|
|
|
|
# communication. (the range means that if the port is busy, it will automatically
|
|
|
|
# try the next port).
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set the bind address specifically (IPv4 or IPv6):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#network.bind_host: 192.168.0.1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set the address other nodes will use to communicate with this node. If not
|
|
|
|
# set, it is automatically derived. It must point to an actual IP address.
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#network.publish_host: 192.168.0.1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set both 'bind_host' and 'publish_host':
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#network.host: 192.168.0.1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set a custom port for the node to node communication (9300 by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#transport.tcp.port: 9300
|
2011-09-22 09:44:12 -04:00
|
|
|
|
2011-09-26 14:32:46 -04:00
|
|
|
# Enable compression for all communication between nodes (disabled by default):
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#transport.tcp.compress: true
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set a custom port to listen for HTTP traffic:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#http.port: 9200
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set a custom allowed content length:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#http.max_content_length: 100mb
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Disable HTTP completely:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#http.enabled: false
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
################################### Gateway ###################################
|
|
|
|
|
|
|
|
# The gateway allows for persisting the cluster state between full cluster
|
|
|
|
# restarts. Every change to the state (such as adding an index) will be stored
|
|
|
|
# in the gateway, and when the cluster starts up for the first time,
|
|
|
|
# it will read its state from the gateway.
|
|
|
|
|
2013-10-09 06:15:24 -04:00
|
|
|
# There are several types of gateway implementations. For more information, see
|
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-gateway.html>.
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# The default gateway type is the "local" gateway (recommended):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#gateway.type: local
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Settings below control how and when to start the initial recovery process on
|
2012-01-22 16:34:34 -05:00
|
|
|
# a full cluster restart (to reuse as much local data as possible when using shared
|
|
|
|
# gateway).
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Allow recovery process after N nodes in a cluster are up:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#gateway.recover_after_nodes: 1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set the timeout to initiate the recovery process, once the N nodes
|
|
|
|
# from previous setting are up (accepts time value):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#gateway.recover_after_time: 5m
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set how many nodes are expected in this cluster. Once these N nodes
|
2012-01-22 16:34:34 -05:00
|
|
|
# are up (and recover_after_nodes is met), begin recovery process immediately
|
|
|
|
# (without waiting for recover_after_time to expire):
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#gateway.expected_nodes: 2
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
############################# Recovery Throttling #############################
|
|
|
|
|
|
|
|
# These settings allow to control the process of shards allocation between
|
|
|
|
# nodes during initial recovery, replica allocation, rebalancing,
|
|
|
|
# or when adding and removing nodes.
|
|
|
|
|
|
|
|
# Set the number of concurrent recoveries happening on a node:
|
|
|
|
#
|
|
|
|
# 1. During the initial recovery
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#cluster.routing.allocation.node_initial_primaries_recoveries: 4
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
|
|
|
# 2. During adding/removing nodes, rebalancing, etc
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#cluster.routing.allocation.node_concurrent_recoveries: 2
|
2011-09-22 09:44:12 -04:00
|
|
|
|
2013-06-28 07:24:32 -04:00
|
|
|
# Set to throttle throughput when recovering (eg. 100mb, by default 20mb):
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#indices.recovery.max_bytes_per_sec: 20mb
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set to limit the number of open concurrent streams when
|
|
|
|
# recovering a shard from a peer:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#indices.recovery.concurrent_streams: 5
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
################################## Discovery ##################################
|
|
|
|
|
|
|
|
# Discovery infrastructure ensures nodes can be found within a cluster
|
|
|
|
# and master node is elected. Multicast discovery is the default.
|
|
|
|
|
|
|
|
# Set to ensure a node sees N other master eligible nodes to be considered
|
2014-08-08 06:43:51 -04:00
|
|
|
# operational within the cluster. This should be set to a quorum/majority of
|
|
|
|
# the master-eligible nodes in the cluster.
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#discovery.zen.minimum_master_nodes: 1
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Set the time to wait for ping responses from other nodes when discovering.
|
|
|
|
# Set this option to a higher value on a slow or congested network
|
|
|
|
# to minimize discovery failures:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#discovery.zen.ping.timeout: 3s
|
2011-09-22 09:44:12 -04:00
|
|
|
|
2013-10-09 06:15:24 -04:00
|
|
|
# For more information, see
|
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-discovery-zen.html>
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# Unicast discovery allows to explicitly control which nodes will be used
|
|
|
|
# to discover the cluster. It can be used when multicast is not present,
|
|
|
|
# or to restrict the cluster communication-wise.
|
|
|
|
#
|
|
|
|
# 1. Disable multicast discovery (enabled by default):
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#discovery.zen.ping.multicast.enabled: false
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
|
|
|
# 2. Configure an initial list of master nodes in the cluster
|
|
|
|
# to perform discovery when new nodes (master or data) are started:
|
|
|
|
#
|
2014-04-17 16:17:51 -04:00
|
|
|
#discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
|
2011-09-22 09:44:12 -04:00
|
|
|
|
|
|
|
# EC2 discovery allows to use AWS EC2 API in order to perform discovery.
|
|
|
|
#
|
|
|
|
# You have to install the cloud-aws plugin for enabling the EC2 discovery.
|
|
|
|
#
|
2013-10-09 06:15:24 -04:00
|
|
|
# For more information, see
|
|
|
|
# <http://elasticsearch.org/guide/en/elasticsearch/reference/current/modules-discovery-ec2.html>
|
2011-09-22 09:44:12 -04:00
|
|
|
#
|
2013-10-09 06:15:24 -04:00
|
|
|
# See <http://elasticsearch.org/tutorials/elasticsearch-on-ec2/>
|
2011-09-22 09:44:12 -04:00
|
|
|
# for a step-by-step tutorial.
|
2011-11-14 07:10:39 -05:00
|
|
|
|
2014-02-05 12:06:39 -05:00
|
|
|
# GCE discovery allows to use Google Compute Engine API in order to perform discovery.
|
|
|
|
#
|
|
|
|
# You have to install the cloud-gce plugin for enabling the GCE discovery.
|
|
|
|
#
|
|
|
|
# For more information, see <https://github.com/elasticsearch/elasticsearch-cloud-gce>.
|
|
|
|
|
|
|
|
# Azure discovery allows to use Azure API in order to perform discovery.
|
|
|
|
#
|
|
|
|
# You have to install the cloud-azure plugin for enabling the Azure discovery.
|
|
|
|
#
|
|
|
|
# For more information, see <https://github.com/elasticsearch/elasticsearch-cloud-azure>.
|
2011-11-14 07:10:39 -05:00
|
|
|
|
|
|
|
################################## Slow Log ##################################
|
|
|
|
|
|
|
|
# Shard level query and fetch threshold logging.
|
|
|
|
|
|
|
|
#index.search.slowlog.threshold.query.warn: 10s
|
|
|
|
#index.search.slowlog.threshold.query.info: 5s
|
|
|
|
#index.search.slowlog.threshold.query.debug: 2s
|
|
|
|
#index.search.slowlog.threshold.query.trace: 500ms
|
|
|
|
|
|
|
|
#index.search.slowlog.threshold.fetch.warn: 1s
|
|
|
|
#index.search.slowlog.threshold.fetch.info: 800ms
|
|
|
|
#index.search.slowlog.threshold.fetch.debug: 500ms
|
|
|
|
#index.search.slowlog.threshold.fetch.trace: 200ms
|
2012-02-07 17:35:28 -05:00
|
|
|
|
2012-12-03 04:21:59 -05:00
|
|
|
#index.indexing.slowlog.threshold.index.warn: 10s
|
|
|
|
#index.indexing.slowlog.threshold.index.info: 5s
|
|
|
|
#index.indexing.slowlog.threshold.index.debug: 2s
|
|
|
|
#index.indexing.slowlog.threshold.index.trace: 500ms
|
|
|
|
|
2012-02-07 17:35:28 -05:00
|
|
|
################################## GC Logging ################################
|
|
|
|
|
2014-01-08 15:15:39 -05:00
|
|
|
#monitor.jvm.gc.young.warn: 1000ms
|
|
|
|
#monitor.jvm.gc.young.info: 700ms
|
|
|
|
#monitor.jvm.gc.young.debug: 400ms
|
2012-02-07 17:35:28 -05:00
|
|
|
|
2014-01-08 15:15:39 -05:00
|
|
|
#monitor.jvm.gc.old.warn: 10s
|
|
|
|
#monitor.jvm.gc.old.info: 5s
|
|
|
|
#monitor.jvm.gc.old.debug: 2s
|
2014-06-19 02:34:38 -04:00
|
|
|
|
|
|
|
################################## Security ################################
|
|
|
|
|
2014-07-29 03:08:23 -04:00
|
|
|
# Uncomment if you want to enable JSONP as a valid return transport on the
|
2014-06-19 02:34:38 -04:00
|
|
|
# http server. With this enabled, it may pose a security risk, so disabling
|
2014-07-29 03:08:23 -04:00
|
|
|
# it unless you need it is recommended (it is disabled by default).
|
2014-06-19 02:34:38 -04:00
|
|
|
#
|
2014-07-29 03:08:23 -04:00
|
|
|
#http.jsonp.enable: true
|