We have a main portal site (running Rails 4 with a PostgreSQL database), and an external image server (running Node.js with Mongo database). I'm trying to establish a connection from Rails to the database - I installed the mongo gem - https://docs.mongodb.org/ecosystem/drivers/ruby/ - and have been following the guide, but got stuck on an odd key error that I can't seem to find any information on.
The image server itself is running fine with no problems (it has a GUI interface that is working fine).
In my controller (I changed the names and left out the passwords):
image_server = Mongo::Client.new([ 'image.companyname.com:####' ], :database => 'db-name')
It seems to connect:
D, [2015-11-11T00:41:22.730360 #9410] DEBUG -- : MONGODB | Adding image.companyname.com:#### to the cluster.
But then just spams this message over and over (and queries don't do anything but return this error even faster).
D, [2015-11-11T00:41:22.991386 #9410] DEBUG -- : MONGODB | key not found: "t"
Eventually it returns one error message as well, but keeps spamming the key not found error as well:
Mongo::Error::NoServerAvailable (No server is available matching preference: #<Mongo::ServerSelector::Primary:0x007f5a943f6ee8 #options={"mode"=>:primary, "database"=>"db-name"}, #tag_sets=[], #server_selection_timeout=30>):
app/controllers/admin/model_controller.rb:9:in `index'
EDIT
I even tried connect directly to the UNIX socket, and got the same error:
image_server = Mongo::Client.new('mongodb://image.companyname.com:####/path/to/socket/socketname.sock')
END EDIT
I'm unsure what the heck this 'key not found "t"' error is, or how to even begin to diagnose this. I've messed with every single connection option I can think of, and nothing changes. Any ideas?
Related
I am using Elasticsearch 6.2.4 with my RoR application using elasticsearch-rails and elasticsearch-model.
My indexation is runninng without getting any errors. but when I try to perform a search from the application I am getting this error from Elasticsearch
<Elasticsearch::Transport::Transport::Errors::BadRequest: [400] {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"}],"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"},"status":400}>
Everything was working normal prior to the upgrade of Elasticsearch from 1.5 to 6.2.4
I simplified my search query to try narrowing down the problem.
q = { "query" => { "match_all" => {} } }
But I still getting the same error. Probably I am not specifying a type in the query but wouldn't be unnecessary since I have a match_all condition ?
> {"query":{"match_all":{}}}
< {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"}],"type":"illegal_argument_exception","reason":"text is empty (possibly HTTP/0.9)"},"status":400}
I am brand new to Elasticsearch so excuse me in advance if there are some evident stuff that I am missing
Do you have any idea what is causing this error ? If you need more specific info just ask and I'll update this question.
Thanks.
Search request from application is resulting in HTTP 400 Bad Request. Are you able to perform a search request from outside the application i.e. invoking a curl command from your local etc ?
I'm new to the field, I'm trying ethereum-ruby to bind Ethereum node into a Rails app.
I have a node running APIs via IPC like
geth --ipcapi "admin,eth,debug,miner,net,shh,txpool,personal,web3"
and in Rails console I can do
client = Ethereum::IpcClient.new("#{ENV['HOME']}/.ethereum/geth.ipc")
but when I try puts client.coinbase["result"] I get and error:
JSON::ParserError: 776: unexpected token at '{"jsonrpc":"2.0","error":{"code":-32600,"message":"EOF"}}
Most likely the call to node resulted in error (no coinbase set?) and therefore there is no "result" field, only "error".
You can also check the other ruby ethereum library ethereum.rb. It was designed to be easy to use for the programmer.
I removed (or decommisioned, can't remember) a DSE analytics node (with IP 10.14.5.50) a couple of months ago. When I now try to execute a dse shark (CREATE TABLE ccc AS SELECT ...) query I now receiving:
15/01/22 13:23:17 ERROR parse.SharkSemanticAnalyzer: org.apache.hadoop.hive.ql.parse.SemanticException: 0:0 Error creating temporary folder on: cfs://10.14.5.50/user/hive/warehouse/mykeyspace.db. Error encountered near token 'TOK_TMP_FILE'
at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.getMetaData(SemanticAnalyzer.java:1256)
at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.getMetaData(SemanticAnalyzer.java:1053)
at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.analyzeInternal(SemanticAnalyzer.java:8342)
at shark.parse.SharkSemanticAnalyzer.analyzeInternal(SharkSemanticAnalyzer.scala:105)
at org.apache.hadoop.hive.ql.parse.BaseSemanticAnalyzer.analyze(BaseSemanticAnalyzer.java:284)
at shark.SharkDriver.compile(SharkDriver.scala:215)
at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:342)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:977)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:888)
at shark.SharkCliDriver.processCmd(SharkCliDriver.scala:347)
at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:413)
at shark.SharkCliDriver$.main(SharkCliDriver.scala:240)
at shark.SharkCliDriver.main(SharkCliDriver.scala)
Caused by: java.lang.RuntimeException: java.io.IOException: Error connecting to node 10.14.5.50:9160 with strategy STICKY.
at org.apache.hadoop.hive.ql.Context.getScratchDir(Context.java:216)
at org.apache.hadoop.hive.ql.Context.getExternalScratchDir(Context.java:270)
at org.apache.hadoop.hive.ql.Context.getExternalTmpFileURI(Context.java:363)
at org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.getMetaData(SemanticAnalyzer.java:1253)
... 12 more
I guess the above error is due to my keyspace referring to the old node:
shark> DESCRIBE DATABASE mykeyspace;
OK
mykeyspace cfs://10.14.5.50/user/hive/warehouse/mykeyspace.db
Time taken: 0.997 seconds
Is there any way for me to fix this incorrect database path?
Tried (but failed) workaround to recreate the database: In cqlsh I created a keyspace thekeyspace and added a table thetable. I the opened up dse hive (and noticed that DESCRIBE DATABASE thekeyspace is giving me a correct cfs path). However, I am unable to drop the the database using DROP DATABASE thekeyspace.
Additional information:
I have no external tables in my keyspace.
Making the SELECT against the tables works.
Setting -hiveconf cassandra.host=WORKING_NODE_IP does not help.
The following commands return proper IP:s (ie. not X.X.X.50):
dsetool listjt
dsetool jobtracker
dsetool sparkmaster
I am getting the same error when I execute the query using dse hive.
No Shark variable is referring to X.X.X.50 when I execute set; in its REPL.
I am running DSE 4.5.
Stumbled across this page that says you need to TRUNCATE "HiveMetaStore"."MetaStore" (in cqlsh) after removing Hive nodes. That did the trick.
My App is down on Heroku which sucks because we have quite a few users now. The worst part is that I have no idea what the error messages mean...
Does anyone know?
2013-05-15T20:55:58+00:00 app[postgres]: [24612-1] [ORANGE] LOG: checkpoint starting: time
2013-05-15T20:55:58+00:00 app[postgres]: [24613-1] [ORANGE] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.000 s, sync=0.000 s, total=0.004 s; sync files=0, longest=0.000 s, average=0.000 s
2013-05-15T20:56:38+00:00 app[heroku-postgres]: source=HEROKU_POSTGRESQL_ORANGE measure.current_transaction=28963 measure.db_size=10396472bytes measure.tables=24 measure.active-connections=5 measure.waiting-connections=0 measure.index-cache-hit-rate=0 measure.table-cache-hit-rate=0.99999
This is the only thing on the logs. I've read the Heroku Postgres log statements but for checkpoint complete it says not action needed....
Any ideas? Any help is appreciated.. Thanks
The problem was the custom domain. Only the A (Host) record on GoDaddy was setup, not the CNAME (Alias). Sometimes a configuration change or deploy can put your app on a different set of EC2 IP addresses, which was the case. So even though the app worked for months without a CNAME, as soon as the EC2 IP address changed the custom domain didn't point there anymore.
I changed the A (Host) record and then added a CNAME (Alias). Now everything is back and working.
Hope this helps someone!
i want to schedule my worker using a cron job to check for database connection periodically (say like 5 mins) and update a memcache key accordingly. so in my app if i find the memcache variable to be set. i render my pages differently then, when the database is up.
But the problem is, the worker doent start when the database is down. when the database is up. it correctly finds out that the database connection is present and update the memcache variable and everything works fine.
I dont know, why worker doesnt start when the database is down.
Am running out on a deadline. any help very much appreciated !
Update:
This is the error i get when the workling doesnt start
/apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/activerecord-2.1.1/lib/active_record/connection_adapters/mysql_adapter.rb:527:in real_connect': Can't connect to MySQL server on '10.223.2.50' (111) (Mysql::Error)
from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:injoin'
from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:in listen'
from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:ineach'
from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:in listen'
from /apps/Symantec/shasta/website/vendor/plugins/workling/script/listen.rb:19
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:203:inload'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:203:in start_load'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:296:instart'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:51:in watch'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:51:infork'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:51:in watch'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:45:ineach'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:45:in watch'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:44:inloop'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:44:in watch'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:84:instart_with_pidfile'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:64:in fork'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:64:instart_with_pidfile'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:111:in start'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application_group.rb:149:increate_monitor'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:283:in start'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/controller.rb:70:inrun'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons.rb:143:in run'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:incall'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in catch_exceptions'
from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons.rb:142:inrun'
from script/workling_starling_client:17
Maybe the worker tries to connect to the database when starting (always) and throws an exception? Have you any errors logged by the worker?
Did you write your worker in Rails? Maybe write a shell script, which will assume the database is down when the worker cannot start?
UPDATE: In your stack trace there is the starting point: script/workling_starling_client:17. What is there, in the line 17?
As the first line (the exception message itself) says that "real_connect': Can't connect to MySQL server on '10.223.2.50' (111) (Mysql::Error)" then it will be enough if you wrap the line 17 (possibly with a few more) in a "rescue" block, and check the error message whether it has the answer you are looking for:
(Of course, don't stop here. Continue your checks, as the lack of exception does not mean that the connection IS established)
begin
line_17_is_here
rescue => e
if e.message =~ /Can't connect to MySQL/
handle_your_no_connection_state
else
raise e
end
end
The question is: can you handle the no-connection state without ActiveRecord?