I am using Redis 7.0.4. I am trying to use RESP3 protocol so that the luascript responses are making more sense. When I use the hello command in luascript, it throws error
This Redis command is not allowed from script
If I set it from command line, it seems to be temporary and fallback to 2.
What is the right way to set it, so my script can take advantage of it?
HELLO is not allowed in Lua script. If you want to switch RESP version in Lua script, you should call redis.setresp(version) instead.
-- use RESP3
redis.setresp(3)
Also, RESP3 support some new types, so you need to be careful with the RESP3 data type conversion from/to Lua types. Check this for detail.
Related
Update - TL'DR:
When it comes to the compilable and cacheable JSR223 Elements, I've saw people using all sorts of tactics dancing around it. I had my doubts and I had my answers here, and found that most of tactics I saw are done wrong:
If your JSR223 scripts are full of args[0], args[1], args[2] everywhere, then that's the wrong choice of tactic, even it is the best practice of JMeter, it is not the best practice in the software engineering and easy-maintenance point of view.
Even if you assign args[n] to some meaningful-named variables, it is not the best practice in JMeter either, as there are much simpler and straightforward ways.
Similarly, if you are following the advices of "using vars.get("") to get variables" (then assign them to some meaningful-named variables), it is not the best practice in JMeter either, as there are much simpler and straightforward ways.
The advice of "Don't use ${} in JSR223 scripts" is more a myth than the truth, as all the ${} using examples in this question are just fine.
Also, the advices of breaking up expressions like "ValidAssetIds_${i+1}_g" with "+" into "ValidCatalogAssetIds_"+ (i+1) + "_g" is just another myth, and in most cases untruth, as illustrated in this question.
Now, as per JMeter's best practices for JSR223:
The reason JSR223 Elements is recommended for intensive load testing over Beanshell or Javascript, is because it implements the Compilable interface, as Groovy scripting engine implements Compilable.
And, it tells people to
ensure
to check (enable) the Cache compiled script if available property to ensure the script compilation is cached
the script does not use any variable using ${varName} as caching would take only first value of ${varName}. Instead use:
vars.get("varName"),
like:
Else, the other option is to pass them as Parameters to the script, like this:
Now, my question are,
What would happen if I use
def my_var = vars.get("MY_VARIABLE")
log.info("The value of my_var is ${my_var}")
in above example? Would log changes in each iteration when MY_VARIABLE changes?
Instead of above, I also tried to use
def my_var2 = __V(MY_VARIABLE)
def my_var3 = ${__V(MY_VARIABLE)}
but somehow I wasn't able to get the values of MY_VARIABLE. What I'm missing?
what if my ${varName} is dynamically defined, what would happen if I use ${varName} in such form? Like,
case 1:
for(def i = 0; i < validAssets.size(); i++) {
vars.put("ValidAssetIds_${i+1}_v","${i+1}")
}
case 2:
def varName = ${__time(/1000,)}
vars.put("MY_Log","abc${varName}")
Would each iteration have their own MY_Log values, or they all will be the same? I know I can guess my conclusion from observations, but the purpose of this question is to let me (or people) know the precautions when it comes to using JSR223 that we might not be aware of before. thanks.
All the "precautions" are described in the documentation
When using this feature, ensure your script code does not use JMeter variables or JMeter function calls directly in script code as caching would only cache first replacement. Instead use script parameters.
For example if you define a random string via User Parameters:
and try to refer it as ${randomString} in Groovy - it will be "random" only during the first iteration, on subsequent iterations the "first" value will be used:
Questions 1 and 3 are using Groovy's string interpolation feature, it's safe to use unless there is a clash with other JMeter Variables names
Question 2: you need to surround the __V() function with quotation marks otherwise the variable value is resolved but it's not defined in Groovy causing compilation error, you should see a message in jmeter.log file regarding it
def my_var2 = "${__V(MY_VARIABLE,)}"
Check out Apache Groovy: What Is Groovy Used For? article for more information on Groovy scripting in JMeter context.
I'm working on a project using Redis cache with cachingFramework.redis.
I already have working the get function with Redis (using FetchObject)
but I need to update the Save function to save in DB and override/update the key/value in Redis.
Should I use SetObject? or I need to call first Remove(key)
It really depends on the when parameter, but by default the SET operation on redis overrides the current value, regardless of its type. Here is the documentation.
So you don't need to call the Remove method.
You can check here how StackExchange.Redis library choose between different SET commands (SET, SETNX, SETEX) depending on the parameters.
I am using TCL-C API for my program.
and I read and created test program that is similar to this C++ example.
But I have a problem with this example. when I use this example in the shell (by loading it with load example.o) every input automatically invokes the interpreter of the API and run the command that is related to the input string.
But suppose that I want that the input will invoke tcl procedure that is inside a package required by me , this procedure will check the parameters and will print another message and only after this will invoke TCL-C API related function (kind of wrapper), In this case how can I do it?
I read somewhere that the symbol # is the symbol should be used for invoking external program but I just can't find where it was.
I will give a small example for make things more clear.
somepackage.tcl
proc dosomething { arg1 , arg2 , arg3 } {
# check args here #
set temp [ #invoke here TCL-C API function and set it's result in temp ]
return $temp
}
package provide ::somepackage 1.0
test.tcl
package require ::somepackage 1.0
load somefile.o # this is the object file which implements TCL-C API commands [doSomething 1 2 3 ]
...
But I have a problem with this example. when I use this example in the
shell (by loading it with load example.o) every input automatically
invokes the interpreter of the API and run the command that is related
to the input string.
Provided that you script snippets represent your actual implementation in an accurate manner, then the problem is that your Tcl proc named doSomething is replaced by the C-implemented Tcl command once your extension is loaded. Procedures and commands live in the same namespace(s). When the loading order were reversed, the problem would remain the same.
I read that everything is being evaluated by the tcl interperter so in
this case I should name the tcl name of the C wrap functions in
special way for example cFunc. But I am not sure about this.
This is correct. You have to organise the C-implemented commands and their scripted wrappers in a way that their names do not conflict with one another. Some (basic) options:
Use two different Tcl namespaces, with same named procedures
Apply some naming conventions to wrapper procs and commands (your cFunc hint)
If your API were provided as actual Itcl or TclOO objects, and the individual commands were the methods, you could use a subclass or a mixin to host refinements (using the super-reference, such as next in TclOO, to forward from the scripted refinement to the C implementations).
A hot-fix solution in your current setup, which is better replaced by some actual design, would be to rename or interp hide the conflicting commands:
load somefile.o
Hide the now available commands: interp hide {} doSomething
Define a scripted wrapper, calling the hidden original at some point:
For example:
proc doSomething {args} {
# argument checking
set temp [interp invokehidden {} doSomething {*}$args]
# result checking
return $temp
}
According to this:
http://www.xmlplease.com/xquery-xhtml
"XQuery does not have a standard way of setting the serialization parameters if available. In XQuery we must look up the proper documentation for the XQuery processor to find out what serialization parameters are implemented if any, and how exactly to use them. If available they can normally be set at the command line. Often they can also be used from inside the XQuery document."
In Saxon you can write something like
declare option saxon:output "omit-xml-declaration=yes";
But there is no mention on how to do it in Zorba XQuery. Can you help? Thank you.
Zorba doesn't implement the XQuery 3.0 prolog options for serialization, yet.
The only way to configure the serializer is using the command line interface (e.g. --omit-xml-declaration) or a host language (e.g. the C++ API).
XQuery_t lQuery = aZorba->compileQuery("for $i in (1 to 3) return <a> { $i } </a>");
Zorba_SerializerOptions lSerOptions;
lSerOptions.omit_xml_declaration = ZORBA_OMIT_XML_DECLARATION_YES;
lQuery->execute(std::cout, &lSerOptions);
Alternatively, you could explicitly serialize the result to a string
fn:serialize($result,
<output:serialization-parameters>
<output:indent value="yes"/>
<output:method value="xml"/>
<output:omit-xml-declaration value="yes"/>
</output:serialization-parameters>
)
and then use the text serialization method (--serialize-text) in the command line interface to output this string.
This is the new official XQuery 3.0 syntax, which is already supported by some XQuery implementations (so I guess it will be implemented in Zorba soon?):
declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
declare option output:omit-xml-declaration "yes";
"your query"
According to the docs ( http://www.zorba-xquery.com/html/documentation/2.1.0/zorba/indexpage#w3cspecs ) Zorba should support the Serialization spec ( http://www.w3.org/TR/xslt-xquery-serialization/#serparam ). In that case it should, if I am not mistaken, be:
declare option omit-xml-declaration "yes";
HTH!
I think zorba doesn't use options to set serialisation parameters. Instead, you'll have to set those parameters as parameters of the serialisation function you're using.
For example, to serialize some XML to a file using zorba 2.x, you culd use the file:write() function. This function takes three parameters:
the file to write to,
the content to write,
and the serialisation parameters:
EDIT: I think it would look like this:
file:write (
'/tmp/test.xml',
$content,
<serialization-parameters>
<omit-xml-declaration>yes</omit-xml-declaration>
</serialization-parameters>
)
This is similar to zorba's 1.4.0 version that offered a generic function ser:serialize() in the serialize module. In general, this is not only application-specific but also version-specific so it may be helpful to know the zorba version you're using.
EDIT: If you're using the command line utility, you can use the option --serialization-parameter, -z to set serialisation parameters:
zorba -z omit-xml-declaration=yes -f -q my_xquery.xq
I am developing an application that will run with a GUI when no commandline args are passed, but can also run invisibly if started from the commandline and passed necessary arguments. I have been asked to include a /version argument that will return a version number. For simplicity this version number can be stored in a variable. Without doing something like writing the version number out to a file, what is the best way for me to return this info to the caller? My app will almost always be started from a script, so the script will have to read the version number and make decisons based on the version.
Google gave me this, should do what you want? reference
If you want to return a value to the caller, you can do change your main() method signature to return an integer instead.
Function Main() As Integer
Note that you can only return an int. If you want something like "1.0.2" you can either come up with a scheme for the numbering (like padding with zeroes etc) or encode it in some way, but that's up to you.
Sorry i am on the move with the ipad, so i cannot do anny testing, but could you not include console, then use console.writeLine(versionstring)
This example from about.com http://visualbasic.about.com/od/usingvbnet/a/CmdLine_3.htm