--- layout: docpage title: "Documentation" is_homepage: false is_sphinx_doc: true doc-parent: "Configuring Cassandra" doc-title: "Cassandra Configuration File" doc-header-links: ' ' doc-search-path: "../search.html" extra-footer: ' ' ---
cluster_name
¶The name of the cluster. This is mainly used to prevent machines in one logical cluster from joining another.
Default Value: ‘Test Cluster’
num_tokens
¶This defines the number of tokens randomly assigned to this node on the ring The more tokens, relative to other nodes, the larger the proportion of data that this node will store. You probably want all nodes to have the same number of tokens assuming they have equal hardware capability.
If you leave this unspecified, Cassandra will use the default of 1 token for legacy compatibility, and will use the initial_token as described below.
Specifying initial_token will override this setting on the node’s initial start, on subsequent starts, this setting will apply even if initial token is set.
If you already have a cluster with 1 token per node, and wish to migrate to multiple tokens per node, see http://wiki.apache.org/cassandra/Operations
Default Value: 256
allocate_tokens_for_keyspace
¶This option is commented out by default.
Triggers automatic allocation of num_tokens tokens for this node. The allocation algorithm attempts to choose tokens in a way that optimizes replicated load over the nodes in the datacenter for the replication strategy used by the specified keyspace.
The load assigned to each node will be close to proportional to its number of vnodes.
Only supported with the Murmur3Partitioner.
Default Value: KEYSPACE
initial_token
¶This option is commented out by default.
initial_token allows you to specify tokens manually. While you can use it with vnodes (num_tokens > 1, above) – in which case you should provide a comma-separated list – it’s primarily used when adding nodes to legacy clusters that do not have vnodes enabled.
hinted_handoff_enabled
¶See http://wiki.apache.org/cassandra/HintedHandoff May either be “true” or “false” to enable globally
Default Value: true
hinted_handoff_disabled_datacenters
¶This option is commented out by default.
When hinted_handoff_enabled is true, a black list of data centers that will not perform hinted handoff
Default Value (complex option):
# - DC1
# - DC2
max_hint_window_in_ms
¶this defines the maximum amount of time a dead host will have hints generated. After it has been dead this long, new hints for it will not be created until it has been seen alive and gone down again.
Default Value: 10800000 # 3 hours
hinted_handoff_throttle_in_kb
¶Maximum throttle in KBs per second, per delivery thread. This will be reduced proportionally to the number of nodes in the cluster. (If there are two nodes in the cluster, each delivery thread will use the maximum rate; if there are three, each will throttle to half of the maximum, since we expect two nodes to be delivering hints simultaneously.)
Default Value: 1024
max_hints_delivery_threads
¶Number of threads with which to deliver hints; Consider increasing this number when you have multi-dc deployments, since cross-dc handoff tends to be slower
Default Value: 2
hints_directory
¶This option is commented out by default.
Directory where Cassandra should store hints. If not set, the default directory is $CASSANDRA_HOME/data/hints.
Default Value: /var/lib/cassandra/hints
hints_flush_period_in_ms
¶How often hints should be flushed from the internal buffers to disk. Will not trigger fsync.
Default Value: 10000
hints_compression
¶This option is commented out by default.
Compression to apply to the hint files. If omitted, hints files will be written uncompressed. LZ4, Snappy, and Deflate compressors are supported.
Default Value (complex option):
# - class_name: LZ4Compressor
# parameters:
# -
batchlog_replay_throttle_in_kb
¶Maximum throttle in KBs per second, total. This will be reduced proportionally to the number of nodes in the cluster.
Default Value: 1024
authenticator
¶Authentication backend, implementing IAuthenticator; used to identify users Out of the box, Cassandra provides org.apache.cassandra.auth.{AllowAllAuthenticator, PasswordAuthenticator}.
Default Value: AllowAllAuthenticator
authorizer
¶Authorization backend, implementing IAuthorizer; used to limit access/provide permissions Out of the box, Cassandra provides org.apache.cassandra.auth.{AllowAllAuthorizer, CassandraAuthorizer}.
Default Value: AllowAllAuthorizer
role_manager
¶Part of the Authentication & Authorization backend, implementing IRoleManager; used to maintain grants and memberships between roles. Out of the box, Cassandra provides org.apache.cassandra.auth.CassandraRoleManager, which stores role information in the system_auth keyspace. Most functions of the IRoleManager require an authenticated login, so unless the configured IAuthenticator actually implements authentication, most of this functionality will be unavailable.
Default Value: CassandraRoleManager
roles_validity_in_ms
¶Validity period for roles cache (fetching granted roles can be an expensive operation depending on the role manager, CassandraRoleManager is one example) Granted roles are cached for authenticated sessions in AuthenticatedUser and after the period specified here, become eligible for (async) reload. Defaults to 2000, set to 0 to disable caching entirely. Will be disabled automatically for AllowAllAuthenticator.
Default Value: 2000
roles_update_interval_in_ms
¶This option is commented out by default.
Refresh interval for roles cache (if enabled). After this interval, cache entries become eligible for refresh. Upon next access, an async reload is scheduled and the old value returned until it completes. If roles_validity_in_ms is non-zero, then this must be also. Defaults to the same value as roles_validity_in_ms.
Default Value: 2000
permissions_validity_in_ms
¶Validity period for permissions cache (fetching permissions can be an expensive operation depending on the authorizer, CassandraAuthorizer is one example). Defaults to 2000, set to 0 to disable. Will be disabled automatically for AllowAllAuthorizer.
Default Value: 2000
permissions_update_interval_in_ms
¶This option is commented out by default.
Refresh interval for permissions cache (if enabled). After this interval, cache entries become eligible for refresh. Upon next access, an async reload is scheduled and the old value returned until it completes. If permissions_validity_in_ms is non-zero, then this must be also. Defaults to the same value as permissions_validity_in_ms.
Default Value: 2000
credentials_validity_in_ms
¶Validity period for credentials cache. This cache is tightly coupled to the provided PasswordAuthenticator implementation of IAuthenticator. If another IAuthenticator implementation is configured, this cache will not be automatically used and so the following settings will have no effect. Please note, credentials are cached in their encrypted form, so while activating this cache may reduce the number of queries made to the underlying table, it may not bring a significant reduction in the latency of individual authentication attempts. Defaults to 2000, set to 0 to disable credentials caching.
Default Value: 2000
credentials_update_interval_in_ms
¶This option is commented out by default.
Refresh interval for credentials cache (if enabled). After this interval, cache entries become eligible for refresh. Upon next access, an async reload is scheduled and the old value returned until it completes. If credentials_validity_in_ms is non-zero, then this must be also. Defaults to the same value as credentials_validity_in_ms.
Default Value: 2000
partitioner
¶The partitioner is responsible for distributing groups of rows (by partition key) across nodes in the cluster. You should leave this alone for new clusters. The partitioner can NOT be changed without reloading all data, so when upgrading you should set this to the same partitioner you were already using.
Besides Murmur3Partitioner, partitioners included for backwards compatibility include RandomPartitioner, ByteOrderedPartitioner, and OrderPreservingPartitioner.
Default Value: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories
¶This option is commented out by default.
Directories where Cassandra should store data on disk. Cassandra will spread data evenly across them, subject to the granularity of the configured compaction strategy. If not set, the default directory is $CASSANDRA_HOME/data/data.
Default Value (complex option):
# - /var/lib/cassandra/data
commitlog_directory
¶This option is commented out by default. commit log. when running on magnetic HDD, this should be a separate spindle than the data directories. If not set, the default directory is $CASSANDRA_HOME/data/commitlog.
Default Value: /var/lib/cassandra/commitlog
cdc_enabled
¶Enable / disable CDC functionality on a per-node basis. This modifies the logic used for write path allocation rejection (standard: never reject. cdc: reject Mutation containing a CDC-enabled table if at space limit in cdc_raw_directory).
Default Value: false
cdc_raw_directory
¶This option is commented out by default.
CommitLogSegments are moved to this directory on flush if cdc_enabled: true and the segment contains mutations for a CDC-enabled table. This should be placed on a separate spindle than the data directories. If not set, the default directory is $CASSANDRA_HOME/data/cdc_raw.
Default Value: /var/lib/cassandra/cdc_raw
disk_failure_policy
¶Policy for data disk failures:
Default Value: stop
commit_failure_policy
¶Policy for commit disk failures:
Default Value: stop
prepared_statements_cache_size_mb
¶Maximum size of the native protocol prepared statement cache
Valid values are either “auto” (omitting the value) or a value greater 0.
Note that specifying a too large value will result in long running GCs and possbily out-of-memory errors. Keep the value at a small fraction of the heap.
If you constantly see “prepared statements discarded in the last minute because cache limit reached” messages, the first step is to investigate the root cause of these messages and check whether prepared statements are used correctly - i.e. use bind markers for variable parts.
Do only change the default value, if you really have more prepared statements than fit in the cache. In most cases it is not neccessary to change this value. Constantly re-preparing statements is a performance penalty.
Default value (“auto”) is 1/256th of the heap or 10MB, whichever is greater
thrift_prepared_statements_cache_size_mb
¶Maximum size of the Thrift prepared statement cache
If you do not use Thrift at all, it is safe to leave this value at “auto”.
See description of ‘prepared_statements_cache_size_mb’ above for more information.
Default value (“auto”) is 1/256th of the heap or 10MB, whichever is greater
key_cache_size_in_mb
¶Maximum size of the key cache in memory.
Each key cache hit saves 1 seek and each row cache hit saves 2 seeks at the minimum, sometimes more. The key cache is fairly tiny for the amount of time it saves, so it’s worthwhile to use it at large numbers. The row cache saves even more time, but must contain the entire row, so it is extremely space-intensive. It’s best to only use the row cache if you have hot rows or static rows.
NOTE: if you reduce the size, you may not get you hottest keys loaded on startup.
Default value is empty to make it “auto” (min(5% of Heap (in MB), 100MB)). Set to 0 to disable key cache.
key_cache_save_period
¶Duration in seconds after which Cassandra should save the key cache. Caches are saved to saved_caches_directory as specified in this configuration file.
Saved caches greatly improve cold-start speeds, and is relatively cheap in terms of I/O for the key cache. Row cache saving is much more expensive and has limited use.
Default is 14400 or 4 hours.
Default Value: 14400
key_cache_keys_to_save
¶This option is commented out by default.
Number of keys from the key cache to save Disabled by default, meaning all keys are going to be saved
Default Value: 100
row_cache_class_name
¶This option is commented out by default.
Row cache implementation class name. Available implementations:
Default Value: org.apache.cassandra.cache.OHCProvider
row_cache_size_in_mb
¶Maximum size of the row cache in memory. Please note that OHC cache implementation requires some additional off-heap memory to manage the map structures and some in-flight memory during operations before/after cache entries can be accounted against the cache capacity. This overhead is usually small compared to the whole capacity. Do not specify more memory that the system can afford in the worst usual situation and leave some headroom for OS block level cache. Do never allow your system to swap.
Default value is 0, to disable row caching.
Default Value: 0
row_cache_save_period
¶Duration in seconds after which Cassandra should save the row cache. Caches are saved to saved_caches_directory as specified in this configuration file.
Saved caches greatly improve cold-start speeds, and is relatively cheap in terms of I/O for the key cache. Row cache saving is much more expensive and has limited use.
Default is 0 to disable saving the row cache.
Default Value: 0
row_cache_keys_to_save
¶This option is commented out by default.
Number of keys from the row cache to save. Specify 0 (which is the default), meaning all keys are going to be saved
Default Value: 100
counter_cache_size_in_mb
¶Maximum size of the counter cache in memory.
Counter cache helps to reduce counter locks’ contention for hot counter cells. In case of RF = 1 a counter cache hit will cause Cassandra to skip the read before write entirely. With RF > 1 a counter cache hit will still help to reduce the duration of the lock hold, helping with hot counter cell updates, but will not allow skipping the read entirely. Only the local (clock, count) tuple of a counter cell is kept in memory, not the whole counter, so it’s relatively cheap.
NOTE: if you reduce the size, you may not get you hottest keys loaded on startup.
Default value is empty to make it “auto” (min(2.5% of Heap (in MB), 50MB)). Set to 0 to disable counter cache. NOTE: if you perform counter deletes and rely on low gcgs, you should disable the counter cache.
counter_cache_save_period
¶Duration in seconds after which Cassandra should save the counter cache (keys only). Caches are saved to saved_caches_directory as specified in this configuration file.
Default is 7200 or 2 hours.
Default Value: 7200
counter_cache_keys_to_save
¶This option is commented out by default.
Number of keys from the counter cache to save Disabled by default, meaning all keys are going to be saved
Default Value: 100
saved_caches_directory
¶This option is commented out by default.
saved caches If not set, the default directory is $CASSANDRA_HOME/data/saved_caches.
Default Value: /var/lib/cassandra/saved_caches
commitlog_sync
¶This option is commented out by default.
commitlog_sync may be either “periodic” or “batch.”
When in batch mode, Cassandra won’t ack writes until the commit log has been fsynced to disk. It will wait commitlog_sync_batch_window_in_ms milliseconds between fsyncs. This window should be kept short because the writer threads will be unable to do extra work while waiting. (You may need to increase concurrent_writes for the same reason.)
Default Value: batch
commitlog_sync
¶the other option is “periodic” where writes may be acked immediately and the CommitLog is simply synced every commitlog_sync_period_in_ms milliseconds.
Default Value: periodic
commitlog_sync_period_in_ms
¶Default Value: 10000
commitlog_segment_size_in_mb
¶The size of the individual commitlog file segments. A commitlog segment may be archived, deleted, or recycled once all the data in it (potentially from each columnfamily in the system) has been flushed to sstables.
The default size is 32, which is almost always fine, but if you are archiving commitlog segments (see commitlog_archiving.properties), then you probably want a finer granularity of archiving; 8 or 16 MB is reasonable. Max mutation size is also configurable via max_mutation_size_in_kb setting in cassandra.yaml. The default is half the size commitlog_segment_size_in_mb * 1024. This should be positive and less than 2048.
NOTE: If max_mutation_size_in_kb is set explicitly then commitlog_segment_size_in_mb must be set to at least twice the size of max_mutation_size_in_kb / 1024
Default Value: 32
commitlog_compression
¶This option is commented out by default.
Compression to apply to the commit log. If omitted, the commit log will be written uncompressed. LZ4, Snappy, and Deflate compressors are supported.
Default Value (complex option):
# - class_name: LZ4Compressor
# parameters:
# -
seed_provider
¶any class that implements the SeedProvider interface and has a constructor that takes a Map<String, String> of parameters will do.
Default Value (complex option):
# Addresses of hosts that are deemed contact points.
# Cassandra nodes use this list of hosts to find each other and learn
# the topology of the ring. You must change this if you are running
# multiple nodes!
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
# seeds is actually a comma-delimited list of addresses.
# Ex: "<ip1>,<ip2>,<ip3>"
- seeds: "<IP_ADDRESS>"
concurrent_reads
¶For workloads with more data than can fit in memory, Cassandra’s bottleneck will be reads that need to fetch data from disk. “concurrent_reads” should be set to (16 * number_of_drives) in order to allow the operations to enqueue low enough in the stack that the OS and drives can reorder them. Same applies to “concurrent_counter_writes”, since counter writes read the current values before incrementing and writing them back.
On the other hand, since writes are almost never IO bound, the ideal number of “concurrent_writes” is dependent on the number of cores in your system; (8 * number_of_cores) is a good rule of thumb.
Default Value: 32
concurrent_writes
¶Default Value: 32
concurrent_counter_writes
¶Default Value: 32
concurrent_materialized_view_writes
¶For materialized view writes, as there is a read involved, so this should be limited by the less of concurrent reads or concurrent writes.
Default Value: 32
file_cache_size_in_mb
¶This option is commented out by default.
Maximum memory to use for sstable chunk cache and buffer pooling. 32MB of this are reserved for pooling buffers, the rest is used as an cache that holds uncompressed sstable chunks. Defaults to the smaller of 1/4 of heap or 512MB. This pool is allocated off-heap, so is in addition to the memory allocated for heap. The cache also has on-heap overhead which is roughly 128 bytes per chunk (i.e. 0.2% of the reserved size if the default 64k chunk size is used). Memory is only allocated when needed.
Default Value: 512
buffer_pool_use_heap_if_exhausted
¶This option is commented out by default.
Flag indicating whether to allocate on or off heap when the sstable buffer pool is exhausted, that is when it has exceeded the maximum memory file_cache_size_in_mb, beyond which it will not cache buffers but allocate on request.
Default Value: true
disk_optimization_strategy
¶This option is commented out by default.
The strategy for optimizing disk read Possible values are: ssd (for solid state disks, the default) spinning (for spinning disks)
Default Value: ssd
memtable_heap_space_in_mb
¶This option is commented out by default.
Total permitted memory to use for memtables. Cassandra will stop accepting writes when the limit is exceeded until a flush completes, and will trigger a flush based on memtable_cleanup_threshold If omitted, Cassandra will set both to 1/4 the size of the heap.
Default Value: 2048
memtable_cleanup_threshold
¶This option is commented out by default.
memtable_cleanup_threshold is deprecated. The default calculation is the only reasonable choice. See the comments on memtable_flush_writers for more information.
Ratio of occupied non-flushing memtable size to total permitted size that will trigger a flush of the largest memtable. Larger mct will mean larger flushes and hence less compaction, but also less concurrent flush activity which can make it difficult to keep your disks fed under heavy write load.
memtable_cleanup_threshold defaults to 1 / (memtable_flush_writers + 1)
Default Value: 0.11
memtable_allocation_type
¶Specify the way Cassandra allocates and manages memtable memory. Options are:
Default Value: heap_buffers
commitlog_total_space_in_mb
¶This option is commented out by default.
Total space to use for commit logs on disk.
If space gets above this value, Cassandra will flush every dirty CF in the oldest segment and remove it. So a small total commitlog space will tend to cause more flush activity on less-active columnfamilies.
The default value is the smaller of 8192, and 1/4 of the total space of the commitlog volume.
Default Value: 8192
memtable_flush_writers
¶This option is commented out by default.
This sets the number of memtable flush writer threads per disk as well as the total number of memtables that can be flushed concurrently. These are generally a combination of compute and IO bound.
Memtable flushing is more CPU efficient than memtable ingest and a single thread can keep up with the ingest rate of a whole server on a single fast disk until it temporarily becomes IO bound under contention typically with compaction. At that point you need multiple flush threads. At some point in the future it may become CPU bound all the time.
You can tell if flushing is falling behind using the MemtablePool.BlockedOnAllocation metric which should be 0, but will be non-zero if threads are blocked waiting on flushing to free memory.
memtable_flush_writers defaults to two for a single data directory. This means that two memtables can be flushed concurrently to the single data directory. If you have multiple data directories the default is one memtable flushing at a time but the flush will use a thread per data directory so you will get two or more writers.
Two is generally enough to flush on a fast disk [array] mounted as a single data directory. Adding more flush writers will result in smaller more frequent flushes that introduce more compaction overhead.
There is a direct tradeoff between number of memtables that can be flushed concurrently and flush size and frequency. More is not better you just need enough flush writers to never stall waiting for flushing to free memory.
Default Value: 2
cdc_total_space_in_mb
¶This option is commented out by default.
Total space to use for change-data-capture logs on disk.
If space gets above this value, Cassandra will throw WriteTimeoutException on Mutations including tables with CDC enabled. A CDCCompactor is responsible for parsing the raw CDC logs and deleting them when parsing is completed.
The default value is the min of 4096 mb and 1/8th of the total space of the drive where cdc_raw_directory resides.
Default Value: 4096
cdc_free_space_check_interval_ms
¶This option is commented out by default.
When we hit our cdc_raw limit and the CDCCompactor is either running behind or experiencing backpressure, we check at the following interval to see if any new space for cdc-tracked tables has been made available. Default to 250ms
Default Value: 250
index_summary_capacity_in_mb
¶A fixed memory pool size in MB for for SSTable index summaries. If left empty, this will default to 5% of the heap size. If the memory usage of all index summaries exceeds this limit, SSTables with low read rates will shrink their index summaries in order to meet this limit. However, this is a best-effort process. In extreme conditions Cassandra may need to use more than this amount of memory.
index_summary_resize_interval_in_minutes
¶How frequently index summaries should be resampled. This is done periodically to redistribute memory from the fixed-size pool to sstables proportional their recent read rates. Setting to -1 will disable this process, leaving existing index summaries at their current sampling level.
Default Value: 60
trickle_fsync
¶Whether to, when doing sequential writing, fsync() at intervals in order to force the operating system to flush the dirty buffers. Enable this to avoid sudden dirty buffer flushing from impacting read latencies. Almost always a good idea on SSDs; not necessarily on platters.
Default Value: false
trickle_fsync_interval_in_kb
¶Default Value: 10240
storage_port
¶TCP port, for commands and data For security reasons, you should not expose this port to the internet. Firewall it if needed.
Default Value: 7000
ssl_storage_port
¶SSL port, for encrypted communication. Unused unless enabled in encryption_options For security reasons, you should not expose this port to the internet. Firewall it if needed.
Default Value: 7001
listen_address
¶Address or interface to bind to and tell other Cassandra nodes to connect to. You _must_ change this if you want multiple nodes to be able to communicate!
Set listen_address OR listen_interface, not both.
Leaving it blank leaves it up to InetAddress.getLocalHost(). This will always do the Right Thing _if_ the node is properly configured (hostname, name resolution, etc), and the Right Thing is to use the address associated with the hostname (it might not be).
Setting listen_address to <IP_ADDRESS> is always wrong.
Default Value: localhost
listen_interface
¶This option is commented out by default.
Set listen_address OR listen_interface, not both. Interfaces must correspond to a single address, IP aliasing is not supported.
Default Value: eth0
listen_interface_prefer_ipv6
¶This option is commented out by default.
If you choose to specify the interface by name and the interface has an ipv4 and an ipv6 address you can specify which should be chosen using listen_interface_prefer_ipv6. If false the first ipv4 address will be used. If true the first ipv6 address will be used. Defaults to false preferring ipv4. If there is only one address it will be selected regardless of ipv4/ipv6.
Default Value: false
broadcast_address
¶This option is commented out by default.
Address to broadcast to other Cassandra nodes Leaving this blank will set it to the same value as listen_address
Default Value: <IP_ADDRESS>
listen_on_broadcast_address
¶This option is commented out by default.
When using multiple physical network interfaces, set this to true to listen on broadcast_address in addition to the listen_address, allowing nodes to communicate in both interfaces. Ignore this property if the network configuration automatically routes between the public and private networks such as EC2.
Default Value: false
internode_authenticator
¶This option is commented out by default.
Internode authentication backend, implementing IInternodeAuthenticator; used to allow/disallow connections from peer nodes.
Default Value: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport
¶Whether to start the native transport server. Please note that the address on which the native transport is bound is the same as the rpc_address. The port however is different and specified below.
Default Value: true
native_transport_port
¶port for the CQL native transport to listen for clients on For security reasons, you should not expose this port to the internet. Firewall it if needed.
Default Value: 9042
native_transport_port_ssl
¶This option is commented out by default. Enabling native transport encryption in client_encryption_options allows you to either use encryption for the standard port or to use a dedicated, additional port along with the unencrypted standard native_transport_port. Enabling client encryption and keeping native_transport_port_ssl disabled will use encryption for native_transport_port. Setting native_transport_port_ssl to a different value from native_transport_port will use encryption for native_transport_port_ssl while keeping native_transport_port unencrypted.
Default Value: 9142
native_transport_max_threads
¶This option is commented out by default. The maximum threads for handling requests when the native transport is used. This is similar to rpc_max_threads though the default differs slightly (and there is no native_transport_min_threads, idle threads will always be stopped after 30 seconds).
Default Value: 128
native_transport_max_frame_size_in_mb
¶This option is commented out by default.
The maximum size of allowed frame. Frame (requests) larger than this will be rejected as invalid. The default is 256MB. If you’re changing this parameter, you may want to adjust max_value_size_in_mb accordingly. This should be positive and less than 2048.
Default Value: 256
native_transport_max_concurrent_connections
¶This option is commented out by default.
The maximum number of concurrent client connections. The default is -1, which means unlimited.
Default Value: -1
native_transport_max_concurrent_connections_per_ip
¶This option is commented out by default.
The maximum number of concurrent client connections per source ip. The default is -1, which means unlimited.
Default Value: -1
rpc_address
¶The address or interface to bind the Thrift RPC service and native transport server to.
Set rpc_address OR rpc_interface, not both.
Leaving rpc_address blank has the same effect as on listen_address (i.e. it will be based on the configured hostname of the node).
Note that unlike listen_address, you can specify <IP_ADDRESS>, but you must also set broadcast_rpc_address to a value other than <IP_ADDRESS>.
For security reasons, you should not expose this port to the internet. Firewall it if needed.
Default Value: localhost
rpc_interface
¶This option is commented out by default.
Set rpc_address OR rpc_interface, not both. Interfaces must correspond to a single address, IP aliasing is not supported.
Default Value: eth1
rpc_interface_prefer_ipv6
¶This option is commented out by default.
If you choose to specify the interface by name and the interface has an ipv4 and an ipv6 address you can specify which should be chosen using rpc_interface_prefer_ipv6. If false the first ipv4 address will be used. If true the first ipv6 address will be used. Defaults to false preferring ipv4. If there is only one address it will be selected regardless of ipv4/ipv6.
Default Value: false
broadcast_rpc_address
¶This option is commented out by default.
RPC address to broadcast to drivers and other Cassandra nodes. This cannot be set to <IP_ADDRESS>. If left blank, this will be set to the value of rpc_address. If rpc_address is set to <IP_ADDRESS>, broadcast_rpc_address must be set.
Default Value: <IP_ADDRESS>
rpc_server_type
¶Cassandra provides two out-of-the-box options for the RPC Server:
The default is sync because on Windows hsha is about 30% slower. On Linux, sync/hsha performance is about the same, with hsha of course using less memory.
Alternatively, can provide your own RPC server by providing the fully-qualified class name of an o.a.c.t.TServerFactory that can create an instance of it.
Default Value: sync
rpc_min_threads
¶This option is commented out by default.
Uncomment rpc_min|max_thread to set request pool size limits.
Regardless of your choice of RPC server (see above), the number of maximum requests in the RPC thread pool dictates how many concurrent requests are possible (but if you are using the sync RPC server, it also dictates the number of clients that can be connected at all).
The default is unlimited and thus provides no protection against clients overwhelming the server. You are encouraged to set a maximum that makes sense for you in production, but do keep in mind that rpc_max_threads represents the maximum number of client requests this server may execute concurrently.
Default Value: 16
rpc_send_buff_size_in_bytes
¶This option is commented out by default.
uncomment to set socket buffer sizes on rpc connections
rpc_recv_buff_size_in_bytes
¶This option is commented out by default.
internode_send_buff_size_in_bytes
¶This option is commented out by default.
Uncomment to set socket buffer size for internode communication Note that when setting this, the buffer size is limited by net.core.wmem_max and when not setting it it is defined by net.ipv4.tcp_wmem See also: /proc/sys/net/core/wmem_max /proc/sys/net/core/rmem_max /proc/sys/net/ipv4/tcp_wmem /proc/sys/net/ipv4/tcp_wmem and ‘man tcp’
internode_recv_buff_size_in_bytes
¶This option is commented out by default.
Uncomment to set socket buffer size for internode communication Note that when setting this, the buffer size is limited by net.core.wmem_max and when not setting it it is defined by net.ipv4.tcp_wmem
thrift_framed_transport_size_in_mb
¶Frame size for thrift (maximum message length).
Default Value: 15
incremental_backups
¶Set to true to have Cassandra create a hard link to each sstable flushed or streamed locally in a backups/ subdirectory of the keyspace data. Removing these links is the operator’s responsibility.
Default Value: false
snapshot_before_compaction
¶Whether or not to take a snapshot before each compaction. Be careful using this option, since Cassandra won’t clean up the snapshots for you. Mostly useful if you’re paranoid when there is a data format change.
Default Value: false
auto_snapshot
¶Whether or not a snapshot is taken of the data before keyspace truncation or dropping of column families. The STRONGLY advised default of true should be used to provide data safety. If you set this flag to false, you will lose data on truncation or drop.
Default Value: true
column_index_size_in_kb
¶Granularity of the collation index of rows within a partition. Increase if your rows are large, or if you have a very large number of rows per partition. The competing goals are these:
Default Value: 64
column_index_cache_size_in_kb
¶Per sstable indexed key cache entries (the collation index in memory mentioned above) exceeding this size will not be held on heap. This means that only partition information is held on heap and the index entries are read from disk.
Note that this size refers to the size of the serialized index information and not the size of the partition.
Default Value: 2
concurrent_compactors
¶This option is commented out by default.
Number of simultaneous compactions to allow, NOT including validation “compactions” for anti-entropy repair. Simultaneous compactions can help preserve read performance in a mixed read/write workload, by mitigating the tendency of small sstables to accumulate during a single long running compactions. The default is usually fine and if you experience problems with compaction running too slowly or too fast, you should look at compaction_throughput_mb_per_sec first.
concurrent_compactors defaults to the smaller of (number of disks, number of cores), with a minimum of 2 and a maximum of 8.
If your data directories are backed by SSD, you should increase this to the number of cores.
Default Value: 1
compaction_throughput_mb_per_sec
¶Throttles compaction to the given total throughput across the entire system. The faster you insert data, the faster you need to compact in order to keep the sstable count down, but in general, setting this to 16 to 32 times the rate you are inserting data is more than sufficient. Setting this to 0 disables throttling. Note that this account for all types of compaction, including validation compaction.
Default Value: 16
sstable_preemptive_open_interval_in_mb
¶When compacting, the replacement sstable(s) can be opened before they are completely written, and used in place of the prior sstables for any range that has been written. This helps to smoothly transfer reads between the sstables, reducing page cache churn and keeping hot rows hot
Default Value: 50
stream_throughput_outbound_megabits_per_sec
¶This option is commented out by default.
Throttles all outbound streaming file transfers on this node to the given total throughput in Mbps. This is necessary because Cassandra does mostly sequential IO when streaming data during bootstrap or repair, which can lead to saturating the network connection and degrading rpc performance. When unset, the default is 200 Mbps or 25 MB/s.
Default Value: 200
inter_dc_stream_throughput_outbound_megabits_per_sec
¶This option is commented out by default.
Throttles all streaming file transfer between the datacenters, this setting allows users to throttle inter dc stream throughput in addition to throttling all network stream traffic as configured with stream_throughput_outbound_megabits_per_sec When unset, the default is 200 Mbps or 25 MB/s
Default Value: 200
read_request_timeout_in_ms
¶How long the coordinator should wait for read operations to complete
Default Value: 5000
range_request_timeout_in_ms
¶How long the coordinator should wait for seq or index scans to complete
Default Value: 10000
write_request_timeout_in_ms
¶How long the coordinator should wait for writes to complete
Default Value: 2000
counter_write_request_timeout_in_ms
¶How long the coordinator should wait for counter writes to complete
Default Value: 5000
cas_contention_timeout_in_ms
¶How long a coordinator should continue to retry a CAS operation that contends with other proposals for the same row
Default Value: 1000
truncate_request_timeout_in_ms
¶How long the coordinator should wait for truncates to complete (This can be much longer, because unless auto_snapshot is disabled we need to flush first so we can snapshot before removing the data.)
Default Value: 60000
slow_query_log_timeout_in_ms
¶How long before a node logs slow queries. Select queries that take longer than this timeout to execute, will generate an aggregated log message, so that slow queries can be identified. Set this value to zero to disable slow query logging.
Default Value: 500
cross_node_timeout
¶Enable operation timeout information exchange between nodes to accurately measure request timeouts. If disabled, replicas will assume that requests were forwarded to them instantly by the coordinator, which means that under overload conditions we will waste that much extra time processing already-timed-out requests.
Warning: before enabling this property make sure to ntp is installed and the times are synchronized between the nodes.
Default Value: false
streaming_keep_alive_period_in_secs
¶This option is commented out by default.
Set keep-alive period for streaming This node will send a keep-alive message periodically with this period. If the node does not receive a keep-alive message from the peer for 2 keep-alive cycles the stream session times out and fail Default value is 300s (5 minutes), which means stalled stream times out in 10 minutes by default
Default Value: 300
phi_convict_threshold
¶This option is commented out by default.
phi value that must be reached for a host to be marked down. most users should never need to adjust this.
Default Value: 8
endpoint_snitch
¶endpoint_snitch – Set this to a class that implements IEndpointSnitch. The snitch has two functions:
CASSANDRA WILL NOT ALLOW YOU TO SWITCH TO AN INCOMPATIBLE SNITCH ONCE DATA IS INSERTED INTO THE CLUSTER. This would cause data loss. This means that if you start with the default SimpleSnitch, which locates every node on “rack1” in “datacenter1”, your only options if you need to add another datacenter are GossipingPropertyFileSnitch (and the older PFS). From there, if you want to migrate to an incompatible snitch like Ec2Snitch you can do it by adding new nodes under Ec2Snitch (which will locate them in a new “datacenter”) and decommissioning the old ones.
Out of the box, Cassandra provides:
You can use a custom Snitch by setting this to the full class name of the snitch, which will be assumed to be on your classpath.
Default Value: SimpleSnitch
dynamic_snitch_update_interval_in_ms
¶controls how often to perform the more expensive part of host score calculation
Default Value: 100
dynamic_snitch_reset_interval_in_ms
¶controls how often to reset all host scores, allowing a bad host to possibly recover
Default Value: 600000
dynamic_snitch_badness_threshold
¶if set greater than zero and read_repair_chance is < 1.0, this will allow ‘pinning’ of replicas to hosts in order to increase cache capacity. The badness threshold will control how much worse the pinned host has to be before the dynamic snitch will prefer other replicas over it. This is expressed as a double which represents a percentage. Thus, a value of 0.2 means Cassandra would continue to prefer the static snitch values until the pinned host was 20% worse than the fastest.
Default Value: 0.1
request_scheduler
¶request_scheduler – Set this to a class that implements RequestScheduler, which will schedule incoming client requests according to the specific policy. This is useful for multi-tenancy with a single Cassandra cluster. NOTE: This is specifically for requests from the client and does not affect inter node communication. org.apache.cassandra.scheduler.NoScheduler - No scheduling takes place org.apache.cassandra.scheduler.RoundRobinScheduler - Round robin of client requests to a node with a separate queue for each request_scheduler_id. The scheduler is further customized by request_scheduler_options as described below.
Default Value: org.apache.cassandra.scheduler.NoScheduler
request_scheduler_options
¶This option is commented out by default.
Scheduler Options vary based on the type of scheduler
Default Value (complex option):
# throttle_limit: 80
# default_weight: 5
# weights:
# Keyspace1: 1
# Keyspace2: 5
request_scheduler_id
¶This option is commented out by default. request_scheduler_id – An identifier based on which to perform the request scheduling. Currently the only valid option is keyspace.
Default Value: keyspace
server_encryption_options
¶Enable or disable inter-node encryption JVM defaults for supported SSL socket protocols and cipher suites can be replaced using custom encryption options. This is not recommended unless you have policies in place that dictate certain settings, or need to disable vulnerable ciphers or protocols in case the JVM cannot be updated. FIPS compliant settings can be configured at JVM level and should not involve changing encryption settings here: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/FIPS.html NOTE No custom encryption options are enabled at the moment The available internode options are : all, none, dc, rack
If set to dc cassandra will encrypt the traffic between the DCs If set to rack cassandra will encrypt the traffic between the racks
The passwords used in these options must match the passwords used when generating the keystore and truststore. For instructions on generating these files, see: http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore
Default Value (complex option):
internode_encryption: none
keystore: conf/.keystore
keystore_password: cassandra
truststore: conf/.truststore
truststore_password: cassandra
# More advanced defaults below:
# protocol: TLS
# algorithm: SunX509
# store_type: JKS
# cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
# require_client_auth: false
# require_endpoint_verification: false
client_encryption_options
¶enable or disable client/server encryption.
Default Value (complex option):
enabled: false
# If enabled and optional is set to true encrypted and unencrypted connections are handled.
optional: false
keystore: conf/.keystore
keystore_password: cassandra
# require_client_auth: false
# Set trustore and truststore_password if require_client_auth is true
# truststore: conf/.truststore
# truststore_password: cassandra
# More advanced defaults below:
# protocol: TLS
# algorithm: SunX509
# store_type: JKS
# cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
internode_compression
¶internode_compression controls whether traffic between nodes is compressed. Can be:
Default Value: dc
inter_dc_tcp_nodelay
¶Enable or disable tcp_nodelay for inter-dc communication. Disabling it will result in larger (but fewer) network packets being sent, reducing overhead from the TCP protocol itself, at the cost of increasing latency if you block for cross-datacenter responses.
Default Value: false
tracetype_query_ttl
¶TTL for different trace types used during logging of the repair process.
Default Value: 86400
tracetype_repair_ttl
¶Default Value: 604800
gc_log_threshold_in_ms
¶This option is commented out by default.
By default, Cassandra logs GC Pauses greater than 200 ms at INFO level This threshold can be adjusted to minimize logging if necessary
Default Value: 200
enable_user_defined_functions
¶If unset, all GC Pauses greater than gc_log_threshold_in_ms will log at INFO level UDFs (user defined functions) are disabled by default. As of Cassandra 3.0 there is a sandbox in place that should prevent execution of evil code.
Default Value: false
enable_scripted_user_defined_functions
¶Enables scripted UDFs (JavaScript UDFs). Java UDFs are always enabled, if enable_user_defined_functions is true. Enable this option to be able to use UDFs with “language javascript” or any custom JSR-223 provider. This option has no effect, if enable_user_defined_functions is false.
Default Value: false
enable_materialized_views
¶Enables materialized view creation on this node. Materialized views are considered experimental and are not recommended for production use.
Default Value: true
windows_timer_interval
¶The default Windows kernel timer and scheduling resolution is 15.6ms for power conservation. Lowering this value on Windows can provide much tighter latency and better throughput, however some virtualized environments may see a negative performance impact from changing this setting below their system default. The sysinternals ‘clockres’ tool can confirm your system’s default setting.
Default Value: 1
transparent_data_encryption_options
¶Enables encrypting data at-rest (on disk). Different key providers can be plugged in, but the default reads from a JCE-style keystore. A single keystore can hold multiple keys, but the one referenced by the “key_alias” is the only key that will be used for encrypt opertaions; previously used keys can still (and should!) be in the keystore and will be used on decrypt operations (to handle the case of key rotation).
It is strongly recommended to download and install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for your version of the JDK. (current link: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html)
Currently, only the following file types are supported for transparent data encryption, although more are coming in future cassandra releases: commitlog, hints
Default Value (complex option):
enabled: false
chunk_length_kb: 64
cipher: AES/CBC/PKCS5Padding
key_alias: testing:1
# CBC IV length for AES needs to be 16 bytes (which is also the default size)
# iv_length: 16
key_provider:
- class_name: org.apache.cassandra.security.JKSKeyProvider
parameters:
- keystore: conf/.keystore
keystore_password: cassandra
store_type: JCEKS
key_password: cassandra
tombstone_warn_threshold
¶When executing a scan, within or across a partition, we need to keep the tombstones seen in memory so we can return them to the coordinator, which will use them to make sure other replicas also know about the deleted rows. With workloads that generate a lot of tombstones, this can cause performance problems and even exaust the server heap. (http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets) Adjust the thresholds here if you understand the dangers and want to scan more tombstones anyway. These thresholds may also be adjusted at runtime using the StorageService mbean.
Default Value: 1000
tombstone_failure_threshold
¶Default Value: 100000
batch_size_warn_threshold_in_kb
¶Log WARN on any multiple-partition batch size exceeding this value. 5kb per batch by default. Caution should be taken on increasing the size of this threshold as it can lead to node instability.
Default Value: 5
batch_size_fail_threshold_in_kb
¶Fail any multiple-partition batch exceeding this value. 50kb (10x warn threshold) by default.
Default Value: 50
unlogged_batch_across_partitions_warn_threshold
¶Log WARN on any batches not of type LOGGED than span across more partitions than this limit
Default Value: 10
compaction_large_partition_warning_threshold_mb
¶Log a warning when compacting partitions larger than this value
Default Value: 100
gc_warn_threshold_in_ms
¶GC Pauses greater than gc_warn_threshold_in_ms will be logged at WARN level Adjust the threshold based on your application throughput requirement By default, Cassandra logs GC Pauses greater than 200 ms at INFO level
Default Value: 1000
max_value_size_in_mb
¶This option is commented out by default.
Maximum size of any value in SSTables. Safety measure to detect SSTable corruption early. Any value size larger than this threshold will result into marking an SSTable as corrupted. This should be positive and less than 2048.
Default Value: 256
back_pressure_enabled
¶Back-pressure settings # If enabled, the coordinator will apply the back-pressure strategy specified below to each mutation sent to replicas, with the aim of reducing pressure on overloaded replicas.
Default Value: false
back_pressure_strategy
¶The back-pressure strategy applied. The default implementation, RateBasedBackPressure, takes three arguments: high ratio, factor, and flow type, and uses the ratio between incoming mutation responses and outgoing mutation requests. If below high ratio, outgoing mutations are rate limited according to the incoming rate decreased by the given factor; if above high ratio, the rate limiting is increased by the given factor; such factor is usually best configured between 1 and 10, use larger values for a faster recovery at the expense of potentially more dropped mutations; the rate limiting is applied according to the flow type: if FAST, it’s rate limited at the speed of the fastest replica, if SLOW at the speed of the slowest one. New strategies can be added. Implementors need to implement org.apache.cassandra.net.BackpressureStrategy and provide a public constructor accepting a Map<String, Object>.
otc_coalescing_strategy
¶This option is commented out by default.
Coalescing Strategies # Coalescing multiples messages turns out to significantly boost message processing throughput (think doubling or more). On bare metal, the floor for packet processing throughput is high enough that many applications won’t notice, but in virtualized environments, the point at which an application can be bound by network packet processing can be surprisingly low compared to the throughput of task processing that is possible inside a VM. It’s not that bare metal doesn’t benefit from coalescing messages, it’s that the number of packets a bare metal network interface can process is sufficient for many applications such that no load starvation is experienced even without coalescing. There are other benefits to coalescing network messages that are harder to isolate with a simple metric like messages per second. By coalescing multiple tasks together, a network thread can process multiple messages for the cost of one trip to read from a socket, and all the task submission work can be done at the same time reducing context switching and increasing cache friendliness of network message processing. See CASSANDRA-8692 for details.
Strategy to use for coalescing messages in OutboundTcpConnection. Can be fixed, movingaverage, timehorizon, disabled (default). You can also specify a subclass of CoalescingStrategies.CoalescingStrategy by name.
Default Value: DISABLED
otc_coalescing_window_us
¶This option is commented out by default.
How many microseconds to wait for coalescing. For fixed strategy this is the amount of time after the first message is received before it will be sent with any accompanying messages. For moving average this is the maximum amount of time that will be waited as well as the interval at which messages must arrive on average for coalescing to be enabled.
Default Value: 200
otc_coalescing_enough_coalesced_messages
¶This option is commented out by default.
Do not try to coalesce messages if we already got that many messages. This should be more than 2 and less than 128.
Default Value: 8
otc_backlog_expiration_interval_ms
¶This option is commented out by default.
How many milliseconds to wait between two expiration runs on the backlog (queue) of the OutboundTcpConnection. Expiration is done if messages are piling up in the backlog. Droppable messages are expired to free the memory taken by expired messages. The interval should be between 0 and 1000, and in most installations the default value will be appropriate. A smaller value could potentially expire messages slightly sooner at the expense of more CPU time and queue contention while iterating the backlog of messages. An interval of 0 disables any wait time, which is the behavior of former Cassandra versions.
Default Value: 200


The modern milkman service, with a twist.
We distribute various types of fresh, high-quality milk products all over the US. Name a location, and we will routinely deliver them there at an affordable rate.
Try our products free for 30 days.
Free TrialHow It Works
Simply fill out the subscription form below, filling out what type of milk product you would like to be delivered to your door. Be sure to include which days you would like have a delivery. You can opt for having your milk powdered, otherwise it will be delivered in glass bottles. Each item has a flat rate of $3.00 per quantity, per day.
You will be assigned a delivery date when you register based on your zip code. You will need to place a cooler outside your home (preferably in the shade) by 6 am. The cooler needs to be able to accommodate bottles that are 11 inches tall and big enough to hold your entire order. Dairy boxes are not supplied, as they can be expensive. If you would prefer a dairy box, there are several options that you can purchase online. The cooler MUST have ice or Icepaks in it. The delivery cannot be complete without them. A good option is to put two or three plastic water bottles in your freezer and reuse them in your cooler weekly.
For more information, please contact us on our number:<PHONE_NUMBER> or send us an email at<EMAIL_ADDRESS>Sourcing
Our Holsteins and Brown Swiss — possibly the oldest of all dairy breeds — graze outdoors from April until November, and during the winter they eat our farm-grown corn and hay. The cows also get silage and a few pounds of grain each day, making for a healthy diet. When they’re healthy, your drinks are too, because it’s reflected in the milk they produce. Just as important as what they eat is what our cows don’t eat. We don’t inject artificial growth hormones to boost milk production or plant crops with genetically modified seeds. We also fertilize with composted manure straight from the cows.
We process our milk as little as allowable to keep the important enzymes and “good” bacteria there to work for you. The fancy term for this old-fashioned method is low-temperature vat pasteurization. The milk is held at 145 degrees for 30 minutes and then cooled as quickly as possible. This gives milk (the kind many of us remember as kids) a smooth, sweet taste and preserves the naturally occurring enzymes that help your body to easily digest it. Granted, this process takes more effort but we don't mind. The great taste is worth every minute. Our milk also is unhomogenized, a rare find these days and a return to nostalgia when a thick layer of cream rose to the top of each bottle.
With our milk you’re getting all of the good, and none of the bad.
 I grew up on a farm in Texas and your milk tastes like back home. They say you can't go home again, but this comes close to those good old days! Thanks for all your fresh products and personable service. - Hunter W.
It's hard to believe that such a company as DairyCarry still exists today. Their personal touch is unparalleled. It's like stepping back into another time when people were proud of their business. The milk is the most delicious you will find anywhere and their powdered variety still taste fresh and are beyond comparison. Unbelievable! - Cassie N.
We are so delighted with the freshness and wonderful taste of the icy cold glass bottled milk. Our milkman Frank is so friendly and dependable; they even come early when a snowstorm is predicted so we won't be caught short of supplies. I can't think of any other business that cares so much about their customers. - Yuki N.
My new neighbors introduced me to the joy of home dairy delivery from the folks at DairyCarry. I grew up in Bolvinia and was astonished that such a service existed in my area. The hormone-free buttermilk milk in recyclable glass bottles, the 2% milk, and other items as well...Friday morning is like heaven when we bring in the week's delivery! - Michael R.
The first month is on us!
Order to your heart's content, as we would love to show you the calibur of our milk, at no cost to you. Please keep in mind that a reoccuring monthly charge will be deducted every month, but we're confident you won't mind! Otherwise, you can contact us and cancel your subscription at no penalty. Shipping is free for orders above $30 and for $10 paid, $1 will be donated to the American Red Floss Association. Thank you for your patronage!


With the Management API, you can programmatically manage checks and integrations in your account.
| Endpoint Name | Endpoint Address |
|---|---|
| Get a list of existing checks | GET SITE_ROOT/api/v1/checks/ |
| Get a single check | GET SITE_ROOT/api/v1/checks/<uuid> GET SITE_ROOT/api/v1/checks/<unique_key> |
| Create a new check | POST SITE_ROOT/api/v1/checks/ |
| Update an existing check | POST SITE_ROOT/api/v1/checks/<uuid> |
| Pause monitoring of a check | POST SITE_ROOT/api/v1/checks/<uuid>/pause |
| Delete check | DELETE SITE_ROOT/api/v1/checks/<uuid> |
| Get a list of check's logged pings | GET SITE_ROOT/api/v1/checks/<uuid>/pings/ |
| Get a list of check's status changes | GET SITE_ROOT/api/v1/checks/<uuid>/flips/ GET SITE_ROOT/api/v1/checks/<unique_key>/flips/ |
| Get a list of existing integrations | GET SITE_ROOT/api/v1/channels/ |
| Get project's badges | GET SITE_ROOT/api/v1/badges/ |
Your requests to SITE_NAME Management API must authenticate using an API key. All API keys are project-specific. There are no account-wide API keys. By default, a project on SITE_NAME doesn't have an API key. You can create read-write and read-only API keys on the Project Settings page.
Only works with the following API endpoints:
Omits sensitive information from the API responses. See the documentation of individual API endpoints for details.
The client can authenticate itself by including an X-Api-Key: <your-api-key>
header in an HTTP request. Alternatively, for POST requests with a JSON request body,
the client can put an api_key
field in the JSON document.
See the Create a new check section for an example.
For POST requests, the SITE_NAME API expects the request body to be
a JSON document (not a multipart/form-data
encoded form data).
SITE_NAME uses HTTP status codes wherever possible. In general, 2xx class indicates success, 4xx indicates a client error, and 5xx indicates a server error.
The response may contain a JSON document with additional data.
GET SITE_ROOT/api/v1/checks/
Returns a list of checks belonging to the user, optionally filtered by one or more tags.
Filters the checks and returns only the checks that are tagged with the specified value.
This parameter can be repeated multiple times.
Example:
SITE_ROOT/api/v1/checks/?tag=foo&tag=bar
curl --header "X-Api-Key: your-api-key" SITE_ROOT/api/v1/checks/
{
"checks": [
{
"name": "Filesystem Backup",
"slug": "filesystem-backup",
"tags": "backup fs",
"desc": "Runs incremental backup every hour",
"grace": 600,
"n_pings": 1,
"status": "up",
"last_ping": "2020-03-24T14:02:03+00:00",
"next_ping": "2020-03-24T15:02:03+00:00",
"manual_resume": false,
"methods": "",
"ping_url": "PING_ENDPOINT31365bce-8da9-4729-8ff3-aaa71d56b712",
"update_url": "SITE_ROOT/api/v1/checks/31365bce-8da9-4729-8ff3-aaa71d56b712",
"pause_url": "SITE_ROOT/api/v1/checks/31365bce-8da9-4729-8ff3-aaa71d56b712/pause",
"channels": "1bdea468-03bf-47b8-ab27-29a9dd0e4b94,51c6eb2b-2ae1-456b-99fe-6f1e0a36cd3c",
"timeout": 3600
},
{
"name": "Database Backup",
"slug": "database-backup",
"tags": "production db",
"desc": "Runs ~/db-backup.sh",
"grace": 1200,
"n_pings": 7,
"status": "down",
"last_ping": "2020-03-23T10:19:32+00:00",
"next_ping": null,
"manual_resume": false,
"methods": "",
"ping_url": "PING_ENDPOINT803f680d-e89b-492b-82ef-2be7b774a92d",
"update_url": "SITE_ROOT/api/v1/checks/803f680d-e89b-492b-82ef-2be7b774a92d",
"pause_url": "SITE_ROOT/api/v1/checks/803f680d-e89b-492b-82ef-2be7b774a92d/pause",
"channels": "1bdea468-03bf-47b8-ab27-29a9dd0e4b94,51c6eb2b-2ae1-456b-99fe-6f1e0a36cd3c",
"schedule": "15 5 * * *",
"tz": "UTC"
}
]
}
The possible values for the status
field are: new
, started
, up
, grace
, down
,
and paused
.
When using the read-only API key, SITE_NAME omits the following fields from responses:
ping_url
, update_url
, pause_url
, channels
. It adds an extra
unique_key
field. The unique_key
identifier is stable across API calls, and
you can use it in the Get a single check
and Get a list of check's status changes API calls.
Example:
{
"checks": [
{
"name": "Filesystem Backup",
"slug": "filesystem-backup",
"tags": "backup fs",
"desc": "Runs incremental backup every hour",
"grace": 600,
"n_pings": 1,
"status": "up",
"last_ping": "2020-03-24T14:02:03+00:00",
"next_ping": "2020-03-24T15:02:03+00:00",
"manual_resume": false,
"methods": "",
"unique_key": "a6c7b0a8a66bed0df66abfdab3c77736861703ee",
"timeout": 3600
},
{
"name": "Database Backup",
"slug": "database-backup",
"tags": "production db",
"desc": "Runs ~/db-backup.sh",
"grace": 1200,
"n_pings": 7,
"status": "down",
"last_ping": "2020-03-23T10:19:32+00:00",
"next_ping": null,
"manual_resume": false,
"methods": "",
"unique_key": "124f983e0e3dcaeba921cfcef46efd084576e783",
"schedule": "15 5 * * *",
"tz": "UTC"
}
]
}
GET SITE_ROOT/api/v1/checks/<uuid>
GET SITE_ROOT/api/v1/checks/<unique_key>
Returns a JSON representation of a single check. Accepts either check's UUID or
the unique_key
(a field derived from UUID and returned by API responses when
using the read-only API key) as an identifier.
curl --header "X-Api-Key: your-api-key" SITE_ROOT/api/v1/checks/<uuid>
{
"name": "Database Backup",
"slug": "database-backup",
"tags": "production db",
"desc": "Runs ~/db-backup.sh",
"grace": 1200,
"n_pings": 7,
"status": "down",
"last_ping": "2020-03-23T10:19:32+00:00",
"next_ping": null,
"manual_resume": false,
"methods": "",
"ping_url": "PING_ENDPOINT803f680d-e89b-492b-82ef-2be7b774a92d",
"update_url": "SITE_ROOT/api/v1/checks/803f680d-e89b-492b-82ef-2be7b774a92d",
"pause_url": "SITE_ROOT/api/v1/checks/803f680d-e89b-492b-82ef-2be7b774a92d/pause",
"channels": "1bdea468-03bf-47b8-ab27-29a9dd0e4b94,51c6eb2b-2ae1-456b-99fe-6f1e0a36cd3c",
"schedule": "15 5 * * *",
"tz": "UTC"
}
The possible values for the status
field are: new
, started
, up
, grace
, down
,
and paused
.
When using the read-only API key, SITE_NAME omits the following fields from responses:
ping_url
, update_url
, pause_url
, channels
. It adds an extra
unique_key
field. This identifier is stable across API calls.
Note: although API omits the ping_url
, update_url
, and pause_url
in read-only
API responses, the client can easily construct these URLs themselves if they know the
check's unique UUID.
{
"name": "Database Backup",
"slug": "database-backup",
"tags": "production db",
"desc": "Runs ~/db-backup.sh",
"grace": 1200,
"n_pings": 7,
"status": "down",
"last_ping": "2020-03-23T10:19:32+00:00",
"next_ping": null,
"manual_resume": false,
"methods": "",
"unique_key": "124f983e0e3dcaeba921cfcef46efd084576e783",
"schedule": "15 5 * * *",
"tz": "UTC"
}
POST SITE_ROOT/api/v1/checks/
Creates a new check and returns its ping URL. All request parameters are optional and will use their default values if omitted.
With this API call, you can create both Simple and Cron checks:
timeout
parameter.schedule
and tz
parameters.string, optional, default value: ""
Name for the new check.
string, optional, default value: ""
A space-delimited list of tags for the new check. Example:
{"tags": "reports staging"}
string, optional.
Description of the check.
number, optional, default value: {{ default_timeout }}.
The expected period of this check in seconds.
Minimum: 60 (one minute), maximum: 31536000 (365 days).
Example for a 5-minute timeout:
{"timeout": 300}
number, optional, default value: {{ default_grace }}.
The grace period for this check in seconds.
Minimum: 60 (one minute), maximum: 31536000 (365 days).
string, optional, default value: "* * * * *
".
A cron expression defining this check's schedule.
If you specify both timeout
and schedule
parameters,
SITE_NAME will create a Cron check and ignore
the timeout
value.
Example for a check running every half-hour:
{"schedule": "0,30 * * "}
string, optional, default value: "UTC".
Server's timezone. This setting only has an effect in combination with the
schedule
parameter.
Example:
{"tz": "Europe/Riga"}
boolean, optional, default value: false.
Controls whether a paused check automatically resumes when pinged (the default) or not. If set to false, a paused check will leave the paused state when it receives a ping. If set to true, a paused check will ignore pings and stay paused until you manually resume it from the web dashboard.
string, optional, default value: "".
Specifies the allowed HTTP methods for making ping requests. Must be one of the two values: "" (an empty string) or "POST".
Set this field to "" (an empty string) to allow HEAD, GET, and POST requests.
Set this field to "POST" to allow only POST requests.
Example:
{"methods": "POST"}
string, optional
By default, this API call assigns no integrations to the newly created check.
Set this field to a special value "*" to automatically assign all existing integrations. Example:
{"channels": "*"}
To assign specific integrations, use a comma-separated list of integration UUIDs. You can look up integration UUIDs using the Get a List of Existing Integrations API call.
Example:
{"channels": "4ec5a071-2d08-4baa-898a-eb4eb3cd6941,746a083e-f542-4554-be1a-707ce16d3acc"}
Alternatively, if you have named your integrations in SITE_NAME dashboard, you can specify integrations by their names. For this to work, your integrations need non-empty unique names, and they must not contain commas. The names must match exactly, whitespace is significant.
Example:
{"channels": "Email to Alice,SMS to Alice"}
array of string values, optional, default value: [].
Enables "upsert" functionality. Before creating a check, SITE_NAME looks for
existing checks, filtered by fields listed in unique
.
If SITE_NAME does not find a matching check, it creates a new check and returns it with the HTTP status code 201.
If SITE_NAME finds a matching check, it updates the existing check and returns it with HTTP status code 200.
The accepted values for the unique
field are
name
, tags
, timeout
, and grace
.
Example:
{"name": "Backups", unique: ["name"]}
In this example, if a check named "Backups" exists, it will be returned.  All request parameters are optional. If you omit any parameter, SITE_NAME will leave its value unchanged.
string, optional.
Name for the check.
string, optional.
A space-delimited list of tags for the check.
Example:
{"tags": "reports staging"}
string, optional.
Description of the check.
number, optional.
The expected period of this check in seconds.
Minimum: 60 (one minute), maximum: 31536000 (365 days).
Example for a 5-minute timeout:
{"timeout": 300}
number, optional.
The grace period for this check in seconds.
Minimum: 60 (one minute), maximum: 31536000 (365 days).
string, optional.
A cron expression defining this check's schedule.
If you specify both timeout
and schedule
parameters,
SITE_NAME will save the schedule
parameter and ignore
the timeout
.
Example for a check running every half-hour:
{"schedule": "0,30 * * "}
string, optional.
Server's timezone. This setting only has an effect in combination with the "schedule" parameter.
Example:
{"tz": "Europe/Riga"}
boolean, optional, default value: false.
Controls whether a paused ping automatically resumes when pinged (the default), or not. If set to false, a paused check will leave the paused state when it receives a ping. If set to true, a paused check will ignore pings and stay paused until you manually resume it from the web dashboard.
string, optional, default value: "".
Specifies the allowed HTTP methods for making ping requests. Must be one of the two values: "" (an empty string) or "POST".
Set this field to "" (an empty string) to allow HEAD, GET, and POST requests.
Set this field to "POST" to allow only POST requests.
Example:
{"methods": "POST"}
string, optional.
Set this field to a special value "*" to automatically assign all existing integrations. Example:
{"channels": "*"}
Set this field to a special value "" (empty string) to automatically unassign all existing integrations. Example:
{"channels": ""}
To assign specific integrations, use a comma-separated list of integration UUIDs. You can look up integration UUIDs using the Get a List of Existing Integrations API call.
Example:
{"channels": "4ec5a071-2d08-4baa-898a-eb4eb3cd6941,746a083e-f542-4554-be1a-707ce16d3acc"}
Alternatively, if you have named your integrations in SITE_NAME dashboard, you can specify integrations by their names. For this to work, your integrations need non-empty and unique names, and they must not contain commas. The names must match exactly, whitespace is significant.
Example:
{"channels": "Email to Alice,SMS to Alice"}
curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc \
--header "X-Api-Key: your-api-key" \
--data '{"name": "Backups", "tags": "prod www", "timeout": 3600, "grace": 60}'
Or, alternatively:
curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc \
--data '{"api_key": "your-api-key", "name": "Backups", "tags": "prod www", "timeout": 3600, "grace": 60}'
{
"channels": "",
"desc": "",
"grace": 60,
"last_ping": null,
"n_pings": 0,
"name": "Backups",
"slug": "backups",
"next_ping": null,
"manual_resume": false,
"methods": "",
"pause_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc/pause",
"ping_url": "PING_ENDPOINTf618072a-7bde-4eee-af63-71a77c5723bc",
"status": "new",
"tags": "prod www",
"timeout": 3600,
"update_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc",
}
POST SITE_ROOT/api/v1/checks/<uuid>/pause
Disables monitoring for a check without removing it. The check goes into a "paused" state. You can resume monitoring of the check by pinging it.
This API call has no request parameters.
curl SITE_ROOT/api/v1/checks/0c8983c9-9d73-446f-adb5-0641fdacc9d4/pause \
--request POST --header "X-Api-Key: your-api-key" --data ""
Note: the --data ""
argument forces curl to send a Content-Length
request header
even though the request body is empty. For HTTP POST requests, the Content-Length
header is sometimes required by some network proxies and web servers.
{
"channels": "",
"desc": "",
"grace": 60,
"last_ping": null,
"n_pings": 0,
"name": "Backups",
"slug": "backups",
"next_ping": null,
"manual_resume": false,
"methods": "",
"pause_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc/pause",
"ping_url": "PING_ENDPOINTf618072a-7bde-4eee-af63-71a77c5723bc",
"status": "paused",
"tags": "prod www",
"timeout": 3600,
"update_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc"
}
DELETE SITE_ROOT/api/v1/checks/<uuid>
Permanently deletes the check from the user's account. Returns JSON representation of the check that was just deleted.
This API call has no request parameters.
curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc \
--request DELETE --header "X-Api-Key: your-api-key"
{
"channels": "",
"desc": "",
"grace": 60,
"last_ping": null,
"n_pings": 0,
"name": "Backups",
"slug": "backups",
"next_ping": null,
"manual_resume": false,
"methods": "",
"pause_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc/pause",
"ping_url": "PING_ENDPOINTf618072a-7bde-4eee-af63-71a77c5723bc",
"status": "new",
"tags": "prod www",
"timeout": 3600,
"update_url": "SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc",
}
GET SITE_ROOT/api/v1/checks/<uuid>/pings/
Returns a list of pings this check has received.
This endpoint returns pings in reverse order (most recent first), and the total number of returned pings depends on the account's billing plan: 100 for free accounts, 1000 for paid accounts.
curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc/pings/ \
--header "X-Api-Key: your-api-key"
{
"pings": [
{
"type": "success",
"date": "2020-06-09T14:51:06.113073+00:00",
"n": 4,
"scheme": "http",
"remote_addr": "<IP_ADDRESS>",
"method": "GET",
"ua": "curl/7.68.0",
"duration": 2.896736
},
{
"type": "start",
"date": "2020-06-09T14:51:03.216337+00:00",
"n": 3,
"scheme": "http",
"remote_addr": "<IP_ADDRESS>",
"method": "GET",
"ua": "curl/7.68.0"
},
{
"type": "success",
"date": "2020-06-09T14:50:59.633577+00:00",
"n": 2,
"scheme": "http",
"remote_addr": "<IP_ADDRESS>",
"method": "GET",
"ua": "curl/7.68.0",
"duration": 2.997976
},
{
"type": "start",
"date": "2020-06-09T14:50:56.635601+00:00",
"n": 1,
"scheme": "http",
"remote_addr": "<IP_ADDRESS>",
"method": "GET",
"ua": "curl/7.68.0"
}
]
}
GET SITE_ROOT/api/v1/checks/<uuid>/flips/
GET SITE_ROOT/api/v1/checks/<unique_key>/flips/
Returns a list of "flips" this check has experienced. A flip is a change of status (from "down" to "up," or from "up" to "down").
Returns the flips from the last value
seconds
Example:
SITE_ROOT/api/v1/checks/<uuid|unique_key>/flips/?seconds=3600
Returns flips that are newer than the specified UNIX timestamp.
Example:
SITE_ROOT/api/v1/checks/<uuid|unique_key>/flips/?start=1592214380
Returns flips that are older than the specified UNIX timestamp.
Example:
SITE_ROOT/api/v1/checks/<uuid|unique_key>/flips/?end=1592217980
curl SITE_ROOT/api/v1/checks/f618072a-7bde-4eee-af63-71a77c5723bc/flips/ \
--header "X-Api-Key: your-api-key"
[
{
"timestamp": "2020-03-23T10:18:23+00:00",
"up": 1
},
{
"timestamp": "2020-03-23T10:17:15+00:00",
"up": 0
},
{
"timestamp": "2020-03-23T10:16:18+00:00",
"up": 1
}
]
GET SITE_ROOT/api/v1/channels/
Returns a list of integrations belonging to the project.
curl --header "X-Api-Key: your-api-key" SITE_ROOT/api/v1/channels/
{
"channels": [
{
"id": "4ec5a071-2d08-4baa-898a-eb4eb3cd6941",
"name": "My Work Email",
"kind": "email"
},
{
"id": "746a083e-f542-4554-be1a-707ce16d3acc",
"name": "My Phone",
"kind": "sms"
}
]
}
GET SITE_ROOT/api/v1/badges/
Returns a map of all tags in the project, with badge URLs for each tag. SITE_NAME provides badges in a few different formats:
svg
: returns the badge as a SVG document.json
: returns a JSON document which you can use to generate a custom badge
yourself.shields
: returns JSON in a Shields.io compatible format.In addition, badges have 2-state and 3-state variations:
svg
, json
, shields
: reports two states: "up" and "down". It
considers any checks in the grace period as still "up".svg3
, json3
, shields3
: reports three states: "up", "late", and "down".The response includes a special *
entry: this pseudo-tag reports the overal status
of all checks in the project.
curl --header "X-Api-Key: your-api-key" SITE_ROOT/api/v1/badges/
{
"badges": {
"backup": {
"svg": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M-2/backup.svg",
"svg3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M/backup.svg",
"json": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M-2/backup.json",
"json3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M/backup.json",
"shields": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M-2/backup.shields",
"shields3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/LOegDs5M/backup.shields"
},
"db": {
"svg": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm-2/db.svg",
"svg3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm/db.svg",
"json": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm-2/db.json",
"json3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm/db.json",
"shields": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm-2/db.shields",
"shields3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/99MuQaKm/db.shields"
},
"prod": {
"svg": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8-2/prod.svg",
"svg3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8/prod.svg",
"json": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8-2/prod.json",
"json3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8/prod.json",
"shields": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8-2/prod.shields",
"shields3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/1TEhqie8/prod.shields"
},
"*": {
"svg": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe-2.svg",
"svg3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe.svg",
"json": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe-2.json",
"json3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe.json",
"shields": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe-2.shields",
"shields3": "SITE_ROOT/badge/67541b37-8b9c-4d17-b952-690eae/9X7kcZoe.shields"
}
}
}


Card will take any credit card form and make it the best part of the checkout process (without you changing anything). Everything is created with pure CSS, HTML, and jQuery — no images required.
When initializing a typeahead, you pass the plugin method one or more datasets. The source of a dataset is responsible for computing a set of suggestions for a given query.
typeahead
Prefetched data is fetched and processed on initialization. If the browser supports local storage, the processed data will be cached there to prevent additional network requests on subsequent page loads.
Remote data is only used when the data provided by local and prefetch is insufficient. In order to prevent an obscene number of requests being made to the remote endpoint, requests are rate-limited.
Custom templates give you full control over how suggestions get rendered making it easy to customize the look and feel of your typeahead. This requires Handlebars.js extension for compilation.
Handlebars.js
Default suggestions can be shown for empty queries by setting the minLength option to 0 and having the source return suggestions for empty queries.
minLength
For more advanced use cases, rather than implementing the source for your dataset yourself, you can take advantage of Bloodhound, the typeahead.js suggestion engine. Bloodhound is stack, flexible, and offers advanced functionalities such as prefetching, intelligent caching, fast lookups, and backfilling with remote data.
Bloodhound
typeahead.js
Multiple datasets give you visually separated sets of data inside Dropdown menu with saperate titles, managed in templates option. This looks like a <optgroup> titles in selects.
saperate titles
templates
<optgroup>
To change the height of your dropdown menu, just wrap your input in some div with custom css styles and change necessary css properties or change it in css directly.
div
custom css
Typeahead supports RTL also. Wrap your input in any div with text-align: right; property and add dir="rtl" to your input, now your dropdown menu is right aligned.
RTL
text-align: right;
Default threshold value is 10. The badge will show up right below the input after entering 10 or more chars. This is default value and position for threshold.
threshold
Use the threshold option to show up badge when there are 15 chars or less
if alwaysShow: true the threshold will be ignored and the remaining length indication will be always showing up while typing or on focus on the input.
alwaysShow: true
warningClass is the class of the element with the indicator. By default is badge badge-success but can be changed to anything you'd like.
warningClass
badge badge-success
limitReachedClass is the class the element gets when the limit is reached. By default is badge badge-important badge-danger but can be changed to anything you'd like.
limitReachedClass
badge badge-important badge-danger
Some attributes are used to change badge format. Attributes : separator,preText,postText,andvalidate.
separator
preText
postText
validate
The field counter can be positioned at the top, bottom, left or right. All you need to do is specify the placement option, with one of those strings. If none is specified, the positioning will be defauted to 'bottom'.
top
You can also place the maxlength indicator on the corners: bottom-right, top-right, top-left and bottom-left.
top-left
You can also place the maxlength indicator inside the input: centered-right.
centered-right
Bootstrap maxlength supports textarea as well as inputs.


Compose
Reflect
Keywords, pictures…
Options
×
DuckDuckGo
Semantics
No Semantics
Keywords
Upload
your own
images…
Upload
Uploading
Done!
Error!
.
Possible Images
Frequency
Word Size
See Common Labels
Hide all Keywords
Show all Keywords
Mood board Color Samples
Export Board
Delete
Front
Back
Crop
Resize
Color
Inspect
Delete
Front
Back
Resize
Color
Inspect
×
Keyword inspector
Text editor
Pick a font
Sans Serif
Serif
Monospace
Size
10
20
30
40
50
60
70
80
90
100
I
B
R
Remove text


 The supported services are: Google Talk, LiveJournal, and Jabber.
You get notified of posts, comments and Web feed updates from your contacts, and you can post your own messages and comments (even to channels!) right from your desktop.
Of course, sometimes you might want to not have all that going on in your Instant Messenger, so you can even stop the updates for a while (we don't mind, honestly - we know you actually need to work sometimes).
To get started, go to your IM client, and add {{IM_BOT}} to your buddy list. Then, send us an IM message containing the text (without the < and >): "SIGN IN <your {{SITE_NAME}} screen name> <your {{SITE_NAME}} password>"
After your account has been verified, you'll start receiving notifications from your contacts. It's that easy!
If you want to stop receiving notifications, you can simply send 'STOP' via IM, and we'll stop.
To post to your stream, you just type in your message and hit Send. You'll get a notification (kinda like an echo) of your post, just so you know it's gone through as it should.
To comment on a post (or a comment), use the @ symbol to direct your comment to a user (example: "@lordi Rock on!") Doing this will add your comment to the most recent thread that person participated in.
If you want to add a new contact, you can FOLLOW [contact] ( e.g. "FOLLOW jyri"). If you want to remove a contact, you can LEAVE [contact].
Similarly, you can join and leave our channels - with JOIN or LEAVE (e.g. "JOIN #squid"). You can also post to channels by prefixing your message with #channelname ( e.g. "#squid Fresh squid fried with lime juice and garlic, served on a bed of crispy noodles = YUMMY!")
{% endblock %}


AuthController
struct AuthController : RouteCollection
The collection of /api/v3/auth/*
route endpoints and handler functions related
to authentication.
API v3 requires the use of either HTTP Basic Authentication
(RFC7617) or HTTP Bearer Authentication
(based on
RFC6750) for virtually all endpoint
access, with very few exceptions carved out for fully public data (such as the Event
Schedule).
This means that essentially all HTTP requests must contain an Authorization
header.
Important
The query-based&key=
scheme used in v2 is not supported at all.
A valid HTTP Basic Authentication
header resembles:
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
The data value in a Basic header is the base64-encoded utf-8 string representation of the user’s username and password, separated by a colon. In Swift, a one-off version might resemble something along the lines of:
var request = URLRequest(...)
let credentials = "username:password".data(using: .utf8).base64encodedString()
request.addValue("Basic \(credentials)", forHTTPHeaderField: "Authorization")
...
Successful execution of sending this request to the login endpoint returns a JSON-encoded token string:
{
"token": "y+jiK8w/7Ta21m/O8F2edw=="
}
which is then used in HTTP Bearer Authentication
for all subsequent requests:
Authorization: Bearer y+jiK8w/7Ta21m/O8F2edw==
A generated token string remains valid across all clients on all devices until the user
explicitly logs out, or it otherwise expires or is administratively deleted. If the user
explicitly logs out on any client on any device, the token is deleted and the
/api/v3/auth/login
endpoint will need to be hit again to generate a new one.
-
Required. Registers routes to the incoming router.
Declaration
Swift
func boot(router: Router) throws
-
POST /api/v3/auth/recovery
Attempts to authorize the user using a combination of
User.username
and any one of theUser.verification
(registration code),User.password
orUser.recoveryKey
(returned byUserController.createHandler(_:data:)
) values.The use case is a forgotten password. While an API client has probably stored the information internally, that doesn’t necessarily help if the user is setting up another client or on another device, and is even less likely to be of use for logging into the web front end.
The intended API client flow here is (a) use this endpoint to obtain an
HTTP Bearer Authentication
token upon success, then (b) use the returned token to immediatelyPOST
to the/api/v3/user/password
endpoint for password change/reset.Note
The
User.verification
registration code can only be used to recover once. This limitation is to prevent a possible race condition in which a malicious user has obtained another’s registration code. After one successful recovery has been executed via the code, subsequent recovery can only be done via the recoveryKey provided during initial account creation.Note
To prevent brute-force malicious attempts, there is a limit on successive failed recovery attempts, currently hard-coded to 5.
Requires
UserRecoveryData
payload in the HTTP body.Throws
400 error if the recovery fails. 403 error if the maximum number of successive failed recovery attempts has been reached. A 5xx response should be reported as a likely bug, please and thank you.
Declaration
Swift
func recoveryHandler(_ req: Request, data: UserRecoveryData) throws -> Future<TokenStringData>
Parameters
req
The incoming
Request
, provided automatically.data
UserRecoveryData
struct containing the username and recoveryKey pair to attempt.Return Value
TokenStringData
containing an authentication token (string) that should be used for all subsequent HTTP requests, until expiry or revocation.
-
POST /api/v3/auth/login
Our basic login handler that utilizes the user’s username and password.
The login credentials are expected to be provided using
HTTP Basic Authentication
. That is, a base64-encoded utf-8 string representation of the user’s username and password, separated by a colon (“username:password”), in theAuthorization
header of thePOST
request. For example:let credentials = "username:password".data(using: .utf8).base64encodedString() request.addValue("Basic \(credentials)", forHTTPHeaderField: "Authorization")
would generate an HTTP header of:
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
There is no payload in the HTTP body; this header field carries all the necessary data. The token string returned by successful execution of this login handler
{ "token": "y+jiK8w/7Ta21m/O8F2edw==" }
is then used for
HTTP Bearer Authentication
in all subsequent requests:Authorization: Bearer y+jiK8w/7Ta21m/O8F2edw==
In order to support the simultaneous use of multiple clients and/or devices by a single user, any existing token will be returned in lieu of generating a new one. A token will remain valid until the user explicitly logs out (or it otherwise expires or is administratively revoked), at which point this endpoint will need to be hit again to generate a new token.
Note
API v2 query parameter style logins and subsequent key submissions are not supported in API v3.
Requires
User.accessLevel
other than.banned
.Throws
401 error if the Basic authentication fails. 403 error if the user is banned. A 5xx response should be reported as a likely bug, please and thank you.
Declaration
Swift
func loginHandler(_ req: Request) throws -> Future<TokenStringData>
Parameters
req
The incoming
Request
, provided automatically.Return Value
TokenStringData
containing an authentication token (string) that should be used for all subsequent HTTP requests, until expiry or revocation.
-
POST /api/v3/auth/logout
Unauthenticates the user and deletes the user’s authentication token. It is the responsibility of the client to respond appropriately to the returned
HTTPStatus
, which should be one of:- 204 No Content
- 401 Unauthorized {“error”: “true”, “reason”: “User not authenticated.”}
- 409 Conflict { “error”: “true”, “reason”: “user is not logged in” }
A 409 response most likely indicates a theoretically possible race condition. There should be no side effect and it is likely harmless, but please do report a 409 error if you encounter one so that the specifics can be looked into.
Throws
401 error if the authentication failed. 409 error if the user somehow wasn’t logged in.Declaration
Swift
func logoutHandler(_ req: Request) throws -> Future<HTTPStatus>
Parameters
req
The incoming
Request
, provided automatically.Return Value
204 No Content if the token was successfully deleted.


What rings true for me?
Compassion, Enthusiasm, Growth, Openness, Personal development. These were the values that jumped out at me when I scanned through the big list. I felt that was the best way to pick some, so I went through once and wrote down each that seemed to resonate with me.
The most important of those that I chose I think would be compassion. Within the past few years or so, as I have matured and learned about myself, I have found that having compassion for others is one of the most powerful and important feelings I can have in my everyday life. I have found that if I take a moment to think about other people in moments of stress, anger, sadness, and even happiness or excitement, it helps shape my view of the world in a much better way. Realizing that every person on the planet has their own story, their own narrative day in and day out, and that each person is just as important as you are will help make every day for you and everyone around you a little bit better.
I would say that for most of those values I would give myself a 4 out of 5 as far as trying to live up to them. I definitely try to think and craft my daily interaction with values like these in mind, but I know that on certain days it just becomes so hard to stick to doing the right thing.
Stereotype threat and compassion
I think that having compassion for people will absolutely be helpful in nullifying stereotype threat. Trying to put myself into others shoes, and realizing that they are in the same boat as me when coming to DBC will help me try to make myself a member of the DBC community, and welcome all others. I think that compassion is key for breaking down barriers put up by stereotypes.
If I ever feel sad or down at DBC, I think taking a break and calling my girlfriend would be my first approach to cheering up. I love her so much and just talking to her helps me destress and realize that problems can sometimes seem massive but can always be overcome.


Data Manipulation
Name:
Age:
Address:
Country:
(Select)
United States
Canada
United Kingdom
France
Brazil
China
Russia
Is Married:
Save


--- layout: article publication-date: 2015-04-18 title: "Skin drag displays: dragging a physical tactor across the user’s skin produces a stronger tactile stimulus than vibrotactile" authors: - Alexandra Ion - Edward Wang - Patrick Baudisch venue: In Proceedings of CHI’15. Seoul, Korea, April 18 – 23, 2015 type: - Conference - Short Paper - Peer-reviewed tags: - Metamaterial - Textures - Fabrication - 3D printing - Programmable matter video: "https://vimeo.com/119650189" video-thumb: "https://vimeo.com/119650188" video-preview: "https://vimeo.com/119650188" image: teaser.jpg pdf: 2015CHI_Skin-drag-displays-authors-copy.pdf doi: https://dl.acm.org/doi/10.1145/2702123.2702459 page-title: "Skin drag displays" page-subtitle: "Dragging a physical tactor across the user’s skin produces a stronger tactile stimulus than vibrotactile." ---
We propose a new type of tactile displays that drag a physical tactor across the skin in 2D. We call this skin drag. We demonstrate how this allows us to communicate geometric shapes or characters to users.The main benefit of our approach is that it simultaneously produces two types of stimuli, i.e.,
(1) it moves a tactile stimulus across skin locations and
(2) it stretches the user’s skin.
Skin drag thereby combines the essential stimuli produced by vibrotactile and skin stretch. In our study, skin drag allowed participants to recognize tactile shapes significantly better than a vibrotactile array of comparable size. We present two arm-worn prototype devices that implement our concept.


Five Largest Protest in U.S History
The tradition of protest that demand progressive change in the United States continue.
Here are the country's five of the top protest in term of attendance:
- George Flyod protest nationwide in 2020 with an estimated 26 million protestors.
- Women's March in 2017 drew about 5.6 million people nationwide.
- March for Our Lives, a student led protest in 2018 againt gun violence, drew about 2 million people.
- Women's March in 2018 drew about 1.5 million protestors.
- March on Washington for Lesbian, Gay, and Bi Equal Rights and Liberation drew about 1 million people in 1993.


When I started this blog, I wanted my blog-posts to be about ideas and experiences. The motive was to write content that never sinks and is somehow able to float through time. This is why I usually shy away from writing blog-posts about frameworks, libraries, or even languages and why I am paranoid about archiving thought-provoking web-pages. However, when I stumbled upon Manim (Mathematical Animation Engine) and explored it for a while, I knew this warranted a blog-post.
Although Grant Sanderson (the author of Manim) likes to call it an animation engine, after playing around for a while, I found it akin to an imagination engine. The ability to craft beautiful animations and text so effortlessly has amazed me the most. Here is a video I made using Manim:
An introduction on Coreference Resolution (the topic of our bachelor thesis)
From what I have observed, Manim renders each animation separately and then combines it to produce the entire video. As I have not explored much of the mathematical side of Manim, I will primarily share links for the text-rendering part.
If some of the Github links are missing, I suggest going to commit aff2d21.
That's it for now!


If this checkbox is selected, an editing position adds to the end of an HTML template ($END$);
if this checkbox is not selected, then the new edit point is not added.
Compare the following:


ALMOST REAL RESUME (GPT3)
use this for your next job application, maybe not.
VIEW CODE
All the contents below are generated using
GPT 3
Reload this page for your next almost real resume!