Memcached lru_crawler metadump doesn't returns END as response - memcached

We are currently working on getting all the keys in Memcached through:
lru_crawler metadump all
For this implementation, we are expecting END or OK at the end of result.
But Memcached doesn't return any response code after the end of data. It just simply returns the metadata.
lru_crawler metadump 1
key=key exp=-1 la=1588598718 cas=1 fetch=no cls=1 size=80
We are using Memcached version 1.4.33.
Is there any configuration that we need to set up for this to return a response code at the end (or) Is there any way that we can find the end of metadump result other than END or OK?
Thanks in advance.

Seems it is a known issue with the Memcahed
https://github.com/memcached/memcached/issues/667

(came across this post when researching a project I'm working on)
It is no longer an issue in current memcache implementations - I'm using 1.5.6 and get 'END'. However it is my experience that this does not always return the full list. I suspect that may be due the order of items in the LRU list changing while command is running (I get 99-100% of the keys when the server is getting hammered).

Related

How can I submit unsubmitted Moodle attempt via SQL

Hello I ma trying to submit unsubmitted quiz attempts so I can grade them. So far I have set the timefinish column in mdl_quiz_attempts which changes the attempt status to "Not yet graded", then setting fraction to 0 from NULL and state to "gradewrong" from "complete" in mdl_question_attempt_steps to simulate submission but this seems to break the site. What am I missing?
You're going to have to trace through the code for the process_finish() function in mod/quiz/attemptlib.php ( https://github.com/moodle/moodle/blob/master/mod/quiz/attemptlib.php#L2171 ) and figure out how that all works.
This is a complex process and will require a lot of DB queries / updates in order to achieve it manually.
I would strongly recommend that you write a PHP script to do this, instead of trying to handle it manually (that way you can create an instance of 'quiz_attempt' for each user's attempt, then call $attempt->process_finish() on each, in order to close the attempt properly).
Thanks. The trick is to set the timefinish column in mdl_quiz_attempts which changes the attempt status to "Not yet graded", then setting the state to "gradewrong" from "complete" in mdl_question_attempt_steps for unsubmitted responses to simulate submission. Then set a fake 0 grade to sumgrades where grades are NULL in mdl_quiz_attempts and then running a regrade in the admin panel.

Why is Gatling failing on a valid jsonpath?

I have the following .check on my returned body: (I changed the values for security reasons but the structure is the same)
.exec(http("Get ids")
.post("GetIds")
.body(ElFileBody("json/getIds.json")).asJson
.check(jsonPath("$...Types..[?(#.Type == 'web')].id").findAll.saveAs("IDLlist"))
But the transaction fails with "Gettting findAll.exists extraction crashed: end of input expected when trying to extract values from a returned body"
Gatling prints the body of the failed transaction, when I take the exact body that the transaction had just failed on to http://jsonpath.com/ and
evaluate the jsonpath that had just failed, I get good results with no issues. This means that the returned body is correct and that the jsonpath is also correct.
What is the issue then?
Thanks to Stephane from the Gatling forum, I found that $..Files[?(#.Format == 'DASH_Web')].URL is correct works instead of the variation that I had.
Since http://jsonpath.com/ was able to extract the correct path using my original syntax, I think its important to note that Gatling jsonpath is much more conservative in its syntax.
It seems your JSON path syntax is wrong --> "$...Types..[?(#.Type == 'web')].id"
Try using JSONPath Online Evaluator -- http://jsonpath.com/ to find correct json syntax

Update in MongoDB Meteor

Is there any scenario that explains why the update is not working, I can't seem to pinpoint the cause and I don't see any errors whatsoever. Is there a way to check the output of the update function because currently the update is not doing anything. That means the last log line shows a value different than 20170615-7702.
Db.find().forEach(function(item){
console.log(item._id+ " =======> " + item.build.parameters.BUILD_NUM);
Db.update({"_id":item._id}, {$set:{"build.parameters.BUILD_NUM":"20170615-7702"}});
console.log(Db.findOne({"_id": item._id}).build.parameters.BUILD_NUM);});
Thank you
The code above should work. I think that the problem above is that it is not able to update the document as fast as it prints the output. First try:
var itemUpdated = Db.findOne({"_id": item._id});
console.log(itemUpdated._id)
The other option is very simple go to the command line and run meteor mongo. Then see all the entries in the collection and their properties.
Third and maybe the best option to test here is to use setTimeout() for the console.log().
Hope it helps.

How to output sets in Gremlin through Orientdb REST API?

In my project, I'm sending Gremlin scripts via the REST API of Orientdb.
I'm having problem returning the values inside sets collected during the graph traversal.
I have a simple Graph setup.
User-- FollowsMovies -- > Movies
User-- FollowsActors -- > Actors
u= g.v('12:1');
following= [] as Set;
u.as('x').out('FollowsMovies').aggregate(following).back('x').out('FollowsActors').aggregate(following);
return following.toString();
however, the script returns nothing. If I ask for size of 'following', it returns 0, although it is not supposed to be empty.
I Tried the same code on the gremlin console and it worked as expected. Can anyone suggest how to correctly output elements of a set?
Thanks for you help in advance.
Try to add iterate()at the end of your query.
See: http://gremlindocs.com/#methods/pipe-iterate

How do I Benchmark RESTful Service with Variable Parameters?

I'm currently working on benchmarking a RESTful service I've made, and part of that is making sure it runs in a reasonable amount of times for a large array of parameters. For example, let's say I have RESTful API of the form some_site.com/item?item_id=y. In that case to be sure my service is working as fast as I'd like it to work, I'd want to try out many values for y one by one, preferably coming from some text file. I can't figure out any way of doing this in ab or httperf. I'm open to using a different benchmarking program if I have, but would prefer something simple and light. What I want to do seems like something pretty standard, so I'm guessing there must already be a program that let's me do it, but an hour or so of googling hasn't gotten me an answer. Ideas?
Answer: Jmeter (which is apparently awesome). This faq explains how to do it. Hopefully this helps someone else, as it took me like a day of searching to figure this out.
I have just had some good experience with using JavaScript (via BSF/Rhino) in JMeter.
I have put one thread group in my test plan and stick a 'Simple Controller' with two elements under it - 'HTTP Request' sampler and 'BSF PreProcessor'.
Set BSF language to 'javascript' and either type the code into the text box or point it to a file (use full path or relative to CWD of JMeter process).
/* Since `Math.random()` gives us float, we use `java.util.Random()`
* see: http://docs.oracle.com/javase/7/docs/api/java/util/Random.html */
var Random = new Packages.java.util.Random();
var min = 10-1;
var max = 2;
var maxLines = (min)+Random.nextInt(max-min);
var s = '';
for (var d = 0; d <= maxLines; d++) {
s += d.toString()+','+Random.nextInt(1000).toString()+'\n';
}
// s => '0,312\n1,104\n2,608\n'
vars.put('PAYLOAD', s);
Now I can refer to ${PAYLOAD} in the HTTP request!
You can generate JSON, but you will need to upgrade jakarta-jmeter-2.5.1/lib/js-1.6R5.jar with the newest version of Rhino to get JSON.stringify and JSON.parse. That worked perfectly for me also, though I thought I'd put a simple example here.
You can use BSF pre-processor for URL params as well, just set another variable with vars.put('X', 'some value') and pass it as ${X} in the request parameter.
This blog post helped quite a bit, by the way.