Scylla 1.7 is supposed to introduce experimental counter columns support, but the functionality seems disabled by default: trying to create a table with a counter column I get:
cassandra.InvalidRequest: Error from server: code=2200 [Invalid query] message="Counter support is not enabled"
How can I enable it?
Thank you
You can enable counters by adding experimental: true to the scylla.yaml
You can read more about 1.7 here http://www.scylladb.com/2017/05/23/scylla-release-version-1-7/
Related
I am trying to make extract information from Spark SQL. Following error message showing while creating extract.
[Simba][Hardy] (35) Error from server: error code: '0' error message: 'org.apache.spark.SparkException: Job aborted due to stage failure: Total size of serialized results of 906 tasks (4.0 GB) is bigger than spark.driver.maxResultSize (4.0 GB)'.
A quick fix is just changing the setting in your execution context.
spark.sql("set spark.driver.maxResultSize = 8G")
Not entirely convinced on Spark SQL Thrift Server, and a little awkward to distill all facts. Tableau uses the results collect'ed to the driver, how else can it get them with Spark?
However:
Set spark.driver.maxResultSize 0 in relevant spark-thrift-sparkconf.conf file will mean no limit (except physicals limits on driver node).
Set spark.driver.maxResultSize 8G or higher in relevant spark-thrift-sparkconf.conf file. Note not all memory on driver can be used.
Or, use Impala Connection for Tableau assuming a Hive Impala source, then less such issues.
Also, number of concurrent users can be a problem. Hence, last point.
Interesting to say the least.
spark.driver.maxResultSize 0
This is the setting you can put in your advanced cluster settings. This will solve your 4 GB issue.
I'm trying to monitor the log file: /var/log/neo4j/debug.log
I'm looking for the text: Application threads blocked for ######ms
I have devised a regular expression for this as: Application threads blocked for (\d+)ms
We want to skip old info: add skip as mode
I want to pull out the number of MS so that the trigger will alert on blockages > 150ms.: \1 must be set as output parameter
I constructed the key as:
log[/var/log/neo4j/debug.log,Application threads blocked for (\d+)ms,,,skip,\1]
in accordance with
log[/path/to/file/file_name,< regexp >,< encoding >,< maxlines >,< mode >,< output >,< maxdelay >]
Type of Information is: Log
Update interval: 30s
History storage period: 90d
Timestamps appear in the log file as: 2018-10-03 13:29:20.460+0000
My timestamp appears as: yyyypMMpddphhpmmpss
I have tried a bunch of different things over the past week trying to get it to stop showing a "Too Many Parameters" error in the GUI without success. I'm completely lost at this point. We have 49 other items working correctly (all others are passive). Active checks are enabled in zabbix_agentd.conf.
I know this is an old thread but it took me a while to solve this problem, so I'd like to share and hope it helps...
According to the Zabbix official documentation the parameters usage for log (and logrt) keys should be:
logrt[file_regexp,<regexp>,<encoding>,<maxlines>,<mode>,<output>,<maxdelay>]
So, if we would use only the "skip" parameter, the item key should look like:
logrt[MyLogFile.log,,,,skip,,]
Nevertheless, it triggers the error "too many parameters".
In fact, to solve this issue I configured this key in my environment with only one coma after the parameter, like this:
logrt["MyLogFile.log","MyFilter",,,skip,]
That's it... hope it helps someone else.
I want to get the entity creation and update dates. Following the answer to this question, I should get them with
GET /v2/entities/myEntity?options=dateCreated,dateModified
In another source, the v2 reference, under the Virtual Attributes section, the options are slighter different: dateCreation and dateModification.
However, no matter which option I use, I always get the error answer:
{
"error": "BadRequest",
"description": "Invalid value for URI param /options/"
}
How can I get them?
Note: I'm using version 0.26 due to Proton/xml compatibility.
The dateCreated and dateModified options were introduced in Orion 0.28.0:
Add: dateCreated and dateModified options to get entity creation and modification times as "virtual" attributes (Issue #876)
Thus, you should upgrade Orion to that version. Note that Orion 0.28.0 stills supporting XML (in fact, it will be the last release supporting it).
Using Couchbase server 2.2 with Java SDK 1.4.4.
The documentation of MemcachedClient::add(String key, int exp, Object o) inherited by CouchbaseClient states: "Add an object to the cache (using the default transcoder) iff it does not exist already".
I haven't found any mention of the atomicy of this operation.
Will asynchronous calls keep the initial value of the added key? Or this is a non-atomic wrapper for a get followed by a set?
Thanks.
add (like most Couchbase operations) is atomic - the cluster will (atomically) perform a check to see if the specified key exists and only if it doesn't will it set it to the given value.
If the key does exist you'll get an error back (EEXISTS or the Java native equivalent).
I am setting up a new Linux-Server and I am editing sshd_config. I will use protocol version 2 (which is default anyway):
Protocol 2
But in the default config-file I also find this two lines:
KeyRegenerationInterval 3600
ServerKeyBits 768
Manpage sshd_config(5) says about KeyRegenerationInterval:
In protocol version 1, the ephemeral server key is automatically
regenerated after this many seconds (if it has been used). The purpose
of regeneration is to prevent decrypting captured sessions by later
breaking into the machine and stealing the keys. The key is never
stored anywhere. If the value is 0, the key is never regenerated. The
default is 3600 (seconds).
So I know what this parameter does in SSH1. But I don't use SSH1. I use the default version SSH2, but the manpage gives no information about the effect of KeyRegenerationInterval in protocol version 2. Has KeyRegenerationInterval any effect in protocol version 2? And what about ServerKeyBits?
What will happen if I leave this settings in the config file when I set Protocol 2? What will happen when I delete those two lines?
I guess that those two parameters are ignored if protocol version is set to 2. But this is just guessed. From what I read until now I can't know for sure. Do you KNOW (not guess) what effect KeyRegenerationInterval and ServerKeyBits have in SSH2?
I'm sure that you already know this. I just didn't want to leave the question unanswered. These options (KeyRegenerationInterval & ServerKeyBits) affect the server key that is generated for SSH protocol 1. You should not have to worry about this if you demand that your connections adhere to protocol 2.
TL;DR: No, these options have no effect in SSH-2 (and SSH-1 support is removed since 2016).
When unsure, source code is the best documentation.
If we search for ServerKeyBits and KeyRegenerationInterval in the entire OpenSSH source code, we find only this in servconf.c:
{ "serverkeybits", sDeprecated, SSHCFG_GLOBAL },
. . .
{ "keyregenerationinterval", sDeprecated, SSHCFG_GLOBAL },
. . .
case sDeprecated:
case sIgnore:
case sUnsupported:
do_log2(opcode == sIgnore ?
SYSLOG_LEVEL_DEBUG2 : SYSLOG_LEVEL_INFO,
"%s line %d: %s option %s", filename, linenum,
opcode == sUnsupported ? "Unsupported" : "Deprecated", arg);
while (arg)
arg = strdelim(&cp);
break;
In other words, both options simply print a deprecation warning and have further no effect.
Then using the blame feature we find that the options were removed in the commit c38ea6348 of Aug 23, 2016 (OpenSSH 7.4p1):
Remove more SSH1 server code: * Drop sshd's -k option. *
Retire configuration keywords that only apply to protocol 1, as well as the
"protocol" keyword. * Remove some related vestiges of protocol 1 support.
Before that they were used only for SSH-1. E.g. KeyRegenerationInterval:
{ "keyregenerationinterval", sKeyRegenerationTime, SSHCFG_GLOBAL },
. . .
case sKeyRegenerationTime:
intptr = &options->key_regeneration_time;
goto parse_time;
Used in sshd.c/L1442:
if ((options.protocol & SSH_PROTO_1) &&
key_used == 0) {
/* Schedule server key regeneration alarm. */
signal(SIGALRM, key_regeneration_alarm);
alarm(options.key_regeneration_time);
key_used = 1;
}
Note: for SSH-2 there's a more powerful RekeyLimit.
For proto 2, there's this :
RekeyLimit
Specifies the maximum amount of data that may be transmitted
before the session key is renegotiated, optionally followed a
maximum amount of time that may pass before the session key is
renegotiated. The first argument is specified in bytes and
may have a suffix of 'K', 'M', or 'G' to indicate Kilobytes,
Megabytes, or Gigabytes, respectively.
The default is between '1G' and '4G', depending on the cipher.
The optional second value is specified in seconds and may use
any of the units documented in the TIME FORMATS section.
The default value for RekeyLimit is default none, which
means that rekeying is performed after the cipher's default
amount of data has been sent or received and no time based
rekeying is done.
Source :
https://www.freebsd.org/cgi/man.cgi?sshd_config(5)