I loaded the imagenet2012 datasets according to the instructions on tensorflow datasets for imagenet2012, and it produced a directory storing the tfrecords under imagenet2012/5.0.0.
But when I reload the dataset, it says
WARNING:absl:Found a different version of the requested dataset: 5.0.0
Using /datasets/imagenet_tar/imagenet2012/5.1.0 instead.
Why is this happening?
If you run as tfds.load('imagenet2012:5.1.0'), the error message should go away
Related
while generating html report through jmeter getting following error message.
note[using jmeter version 5.4.1]
Generating report
An error occurred: Data exporter "html" is unable to export data.
The Data exporter "html" is unable to export data message unfortunately doesn't contain either root cause of the issue or at least a clue.
You need to take a look at jmeter.log file, it should contain way more information regarding the failure.
The most common reasons are:
Lack of JVM Heap space
Impossibility to write to the destination folder (lack of permissions, disk full, etc.)
Issues with .jtl results file (i.e. you ran your test on another JMeter instance having different Results File Configuration)
Also be informed that according to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.5 (or whatever is the latest version available at JMeter Downloads page) on next available opportunity.
When uploading a geojson file into a map, Kibana hangs indefinitely on "Writing to index".
It's the same issue as in this fixed bug: https://github.com/elastic/kibana/issues/40102
I have Kibana v7.6.1, so it should be fixed in this version.
The index I want to use is one of these (I think this is the website I got it from): https://datamillnorth.org/dataset/ons-ward-boundaries
The geojson file is only 1.7 MB. I've had the same problem with all the other geojson files I've tried. I haven't successfully uploaded any geojson files.
If I look in Index Management, the index is present, but it doesn't come up as an option when I make a new map and try to add an index layer.
Bug report on Kibana: https://github.com/elastic/kibana/issues/61794
It relates to an elastic search and it's because the file I was using is bad.
I used the mapshaper CLI to fix the file: https://github.com/mbloch/mapshaper/wiki/Introduction-to-the-Command-Line-Tool
mapshaper -i leeds.geojson -clean -o leeds_fixed.geojson
This originally didn't work with the file I had. I got a different version of the file from a different website (https://martinjc.github.io/UK-GeoJSON/), and ran the above CLI, and it fixed the problem in Kibana.
SDK: Apache Beam SDK for Go 0.5.0
We are running Apache Beam Go SDK jobs in Google Cloud Data Flow. They had been working fine until recently when they intermittently stopped working (no changes made to code or config). The error that occurs is:
Failed to retrieve staged files: failed to retrieve worker in 3 attempts: bad MD5 for /var/opt/google/staged/worker: ..., want ; bad MD5 for /var/opt/google/staged/worker: ..., want ;
(Note: It seems as if it's missing a second hash value in the error message message.)
As best I can guess there's something wrong with the worker - It seems to be trying to compare md5 hashes of the worker and missing one of the values? I don't know exactly what it's comparing to though.
Does anybody know what could be causing this issue?
The fix to this issue seems to have been to rebuild the worker_harness_container_image with the latest changes. I had tried this but I didn't have the latest release when I built it locally. After I pulled the latest from the Beam repo, and rebuilt the image (As per the notes here https://github.com/apache/beam/blob/master/sdks/CONTAINERS.md) and reran it seemed to work again.
I'm seeing the same thing. If I look into the Stackdriver logging I see this:
Handler for GET /v1.27/images/apache-docker-beam-snapshots-docker.bintray.io/beam/go:20180515/json returned error: No such image: apache-docker-beam-snapshots-docker.bintray.io/beam/go:20180515
However, I can pull the image just fine locally. Any ideas why Dataflow cannot pull.
We are looking at upgrading our CouchDB on our RHEL servers from 1.6.1 to 2.1.1. Before we do that, though, we wanted to run a performance test. So we created a JMeter test that goes directly against the database. It does not use any random values, so that the test would be exactly the same, and we could compare the two results. This is just a standalone server, we are not using clustering. I ran the tests the exacts same way for both. I ran the tests for 1.6.1, and then installed 2.1.1 on the same machine. And I created the database new for each test run. [I also updated Erlang to R19.3.]
The results were very shocking:
Average response times:
1.6.1: 271.15 ms
2.1.1: 494.32 ms
POST and PUTs were really bad ...
POST:
1.6.1: 38.25 ms
2.1.1: 250.18 ms
PUT:
1.6.1: 37.33 ms
2.1.1: 358.76
We are just using the default values for all the config options, except that we changed 1.6.1 to have delayed_commits = false (that is now the default in 2.1.1). I'm wondering if there's some default that changed that would make 2.1.1 so bad.
When I ran the CouchDB setup from the Fauxton UI, it added the following to my local.ini:
[cluster]
n = 1
Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all? One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.
Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all?
It's not obvious from your description. If you setup CouchDB 2.0 as clustered then that's how it will work. This is something you should know depending on the setup instructions you followed: http://docs.couchdb.org/en/2.1.1/install/setup.html
You can tell by locating the files on disk and seeing if they are in a shards directory or not.
I'm pretty sure you want at least two, so setting n = 1 doesn't seem like something you should be doing.
If you're trying to run in single node follow the instructions I linked above to do that.
One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.
You probably don't want to delete random parts of your database unless there are instructions saying this is OK?
We have an aerospike cluster with 3 nodes (v. 3.7.4)
We encountered a problem with udf. We registered new version of udf file, but when we query we get the same results as before.
From the aql when we do show modules we see that the hash of the file has changed, for testing purposes I've added a new function to the same file, then in aql when I use aggregate with that new function it says that the function does not found. We removed the module, dropped the cache in each node, then registered module again, and nothing seems to help to solve the problem. Here is the screen:
asinfo -v build
3.7.4
aql> aggregate invoices_udf.filter_by_merchant('FOOD-CULTURA-ESENTAI') on dareco.invoices
2017-01-06 15:13:27 ERROR Lua Runtime Error: function not found
Error: (100) UDF: Execution Error 2 : function not found
aql> show modules
+--------------------------------------------+---------------------+-------+
| hash | module | type |
+--------------------------------------------+---------------------+-------+
| "18092674658a4edb345acd1e44941755ab962db1" | "statistics.lua" | "lua" |
| "95357d821687372af7d9d8d3f8cc591df5ccfee3" | "invoices_udf.lua" | "lua" |
We also tried to reload the cluster. Turned off the udf cache. Nothing helped.
For aggregations, your udf has to be loaded both on server nodes and client node. AQL will load it on the server node, so it works well for Record UDFs. For Aggregations, to load on client node, you should use the API call in the client to register the udf and also make sure when you connect to the cluster, in your connection configuration, you identify the lua user_path for the client node, ensure client userid has write access to that path, and system path for Aerospike lua modules to be loaded on the client node is also correctly identified in the connection config especially if using node.js or python clients. For details, see discussion at: https://discuss.aerospike.com/t/aerospikeerror-udf-execution-error-1/3801/13
(Posting this because restarting the cluster or rebuilding SIs is probably not related to your original aggregation issue.)
We have solved the problem by backing up the data, then restarting the cluster, importing data from the backup, recreating all the indices we had and deleting old unnecessary data.