I updated DSE to 5.1.2 and enabled DSE Unified Authentication.
When I run "dse -u xxx -p xxx spark", I get a shell, but if i submit a query using "spark.sql" I get an error:
scala> val result = spark.sql("SELECT id FROM xxx.yyy")
java.lang.RuntimeException: com.datastax.bdp.fs.client.InternalServerException: Server returned HTTP error response 500 (Internal Server Error)
Caused by: com.datastax.bdp.fs.client.InternalServerException: Server returned HTTP error response 500 (Internal Server Error)
at com.datastax.bdp.fs.client.DseFsClient$stateMachine$macro$1$1.apply(DseFsClient.scala:132)
In /var/log/cassandra/system.log I see:
WARN [Native-Transport-Requests-2] 2017-08-31 12:05:29,057 DseAuthenticator.java:659 - Plain text authentication without client / server encryption is strongly discouraged
ERROR [dsefs-netty-worker-4] 2017-08-31 12:05:29,842 DSEFS RestServerHandler.scala:287 - [id: 0x1810ea2d, L:/10.225.155.31:5598 - R:/10.225.155.31:58006] RestHandler invocation failed
java.util.concurrent.ExecutionException: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried)
at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299) ~[guava-18.0.jar:na]
Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried)
Any idea how to fix this. By the way, dse spark-submit works...
The problem was solved by enabling dsefs in dse.yaml.
I'm building an app using Nativescript/Angular 2 and I'm also using a javascript library to use websockets connecting it with an Actioncable Rails app.
When trying to establish connection I get a websocket error code 1006 on the Nativescript log console and the connection gets closed.
I noticed that the initial HTTP (the handshake) request sends two values for Sec-WebSocket-Protocol on the header (actioncable-v1-json, actioncable-unsupported) but the headers in the response have only one value for Sec-WebSocket-Protocol which is 'actioncable-v1-json' and 'actioncable-unsupported' is missing.
I believe this error happens because of the missing protocol in the response.
Does anyone know how to add this header (actioncable-unsupported) to the handshake response? Or any other ideas of what is causing this error?
There is no error in the rails log, it just gets connected and then disconnected:
Started GET "/v1/cable/" [WebSocket] for 192.168.1.8 at 2017-04-02 17:04:06 -0700
Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: upgrade, HTTP_UPGRADE: websocket)
Finished "/v1/cable/" [WebSocket] for 192.168.1.8 at 2017-04-02 17:04:06 -0700
The error message displayed on the Nativescript console is this:
CONSOLE LOG file:///app/tns_modules/nativescript-actioncable/lib/action_cable.js:46:33: [ActionCable] Opening WebSocket, current state is null, subprotocols: actioncable-v1-json,actioncable-unsupported 1491179483038
CONSOLE LOG file:///app/tns_modules/nativescript-actioncable/lib/action_cable.js:46:33: [ActionCable] ConnectionMonitor started. pollInterval = 3000 ms 1491179483042
CONSOLE LOG file:///app/tns_modules/nativescript-actioncable/lib/action_cable.js:46:33: [ActionCable] Socket was closed because: code: 1006 1491179483109
Thank you
I was having this issue and the issue was the cable.yml configuration.
We noticed that the staging environment had this value for url:
url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>
Removing that value and actually other values fixed it for us.
New cable.yml staging config:
staging:
adapter: redis
Working!
EDIT: Shown at end, found that upgrade headers were actually created.
I'm working from the action-cable-example codebase, trying to build a WebSocket app. The "Chatty" application, which depends upon the browser client provided in the app, works fine. But, I am not going to use that client as I need an external IoT connection. As a result, I am trying to implement the ws/wss WebSocket protocols to external non-browser devices and my connection in route.rb is:
mount ActionCable.server => '/cable'
I've tried several external clients, such as the Chrome Simple WebSocket Client extension and gem websocket-client-simple using sample/client.rb. In both cases, ActionCable returns no upgrade headers. The Chrome Extension complains as follows:
WebSocket connection to 'ws://127.0.0.1:3000/cable' failed: Error during WebSocket handshake: 'Upgrade' header is missing
The actual handshake shows that to be true, as in:
**General**
Request URL:ws://127.0.0.1:3000/cable
Request Method:GET
Status Code:101 Switching Protocols
**Response Headers**
view source
Connection:keep-alive
Server:thin
**Request Headers**
view source
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:Upgrade
Cookie:PPA_ID=<redacted>
DNT:1
Host:127.0.0.1:3000
Origin:chrome-extension://pfdhoblngboilpfeibdedpjgfnlcodoo
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:1vokmzewcWf9e2RwMth0Lw==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
Per the standards, the response headers are to be this:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
The Sec-WebSocket-Accept is particularly important, as it's a calculation based on the request header's Sec-WebSocket-Key to confirm that ws/wss is understood and that the the Switching Protocols should occur.
During all of this, the server is more happy, until the client gets ticked and closes the connection:
Started GET "/cable" for 127.0.0.1 at 2016-06-16 19:19:17 -0400
ActiveRecord::SchemaMigration Load (1.0ms) SELECT "schema_migrations".* FROM "schema_migrations"
Started GET "/cable/" [WebSocket] for 127.0.0.1 at 2016-06-16 19:19:17 -0400
Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE: websocket)
Finished "/cable/" [WebSocket] for 127.0.0.1 at 2016-06-16 19:19:18 -0400
Looking at websocket-client-simple, I broke down the WebSocket returned to client.rb, and it also showed empty headers. I am showing the code and then the WebSocket:
url = ARGV.shift || 'ws://localhost:3000/cable'
ws = WebSocket::Client::Simple.connect url
#<WebSocket::Client::Simple::Client:0x2cdaf68
#url="ws://localhost:3000/cable",
#socket=#<TCPSocket:fd 3>,
#handshake=<WebSocket::Handshake::Client:0x013231c8
#url="ws://localhost:3000/cable",
#headers={},
#state=:new,
#handler=#<WebSocket::Handshake::Handler::Client11:0x2e88400
#handshake=<WebSocket::Handshake::Client:0x013231c8
#url="ws://localhost:3000/cable",
#headers={},
#state=:new,
#handler=#<WebSocket::Handshake::Handler::Client11:0x2e88400 ...>,
#data="",
#secure=false,
#host="localhost",
#port=3000,
#path="/cable",
#query=nil,
#version=13>,
#key="KUJ0/C0rvoCMruW8STp0Sw==">,
#data="",
#secure=false,
#host="localhost",
#port=3000,
#path="/cable",
#query=nil,
#version=13>,
#handshaked=false,
#pipe_broken=false,
#closed=false,
#__events=[{:type=>:__close, :listener=>#<Proc:0x2d10ae8#D:/Bitnami/rubystack-2.2.5-3/projects/websocket-client-simple/lib/websocket-client-simple/client.rb:37>, :params=>{:once=>true}, :id=>0}],
#thread=#<Thread:0x2d10a70#D:/Bitnami/rubystack-2.2.5-3/projects/websocket-client-simple/lib/websocket-client-simple/client.rb:42 sleep>
>;
In this response, I noted the instance variable "#handshaked" is returned as false. That may be relevant, but I haven't found where that is set or referenced within the code so far.
UPDATE:
Found that WebSocket::Driver.start actually creates the upgrade headers. And, #socket.write(response) should send them out through EventMachine.
Code:
def start
return false unless #ready_state == 0
response = handshake_response
return false unless response
#socket.write(response)
open unless #stage == -1
true
end
handshake_response is:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: iJVnsG1ApNMFzABXGDSHN1V0i/s=
The problem was that I was trying to use the Thin server in development. It would operate. However, it was actually transmitting the response headers during its processing, such as this:
Response Headers
Connection:keep-alive
Server:thin
ActionCable was actually sending the appropriate upgrade headers, but it was doing so only after Thin had sent out its own headers so the client didn't recognize them.
After converting back to Puma, I receive these as expected:
Response Headers
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: XJOmp1e2IwQIMk5n0JV/RZZSIhs=
I'm working on a fairly large Rails 3 project that by default is run on localhost:5000 for development. I'm currently migrating our web server from unicorn to puma. However, when I run my development server, I constantly get these kinds of errors:
16:11:39 web.1 | 2015-07-02 16:11:39 -0500: HTTP parse error, malformed request (): #<Puma::HttpParserError: Invalid HTTP format, parsing fails.>
16:11:39 web.1 | 2015-07-02 16:11:39 -0500: ENV: {"rack.version"=>[1, 1], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "SCRIPT_NAME"=>"", "CONTENT_TYPE"=>"text/plain", "QUERY_STRING"=>"txtAirPlay&txtRAOP", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"2.11.2", "GATEWAY_INTERFACE"=>"CGI/1.2", "REQUEST_METHOD"=>"GET", "REQUEST_PATH"=>"/info", "REQUEST_URI"=>"/info?txtAirPlay&txtRAOP"}
16:11:39 web.1 | ---
Research indicates that this is because OS X Yosemite uses port 5000 for AirPlay streaming. I'm looking for a way to remove these errors from my stdout.
I can't figure out if there's a way to disable AirPlay temporarily, or even if I should be doing that.
I can't feasibly just change the port my application runs on - this is a fairly large project with a lot of contributors. Trying to just change the port locally sends me down a rabbit hole.
Is there a way to either silently reject these requests or just simply filter them from my stdout? I'm worried I'm missing important signals amongst this noise.
I'm using Apache + passenger for my rails application, The application is running fine in production mode except when the browser displays error message after every 2-3 clicks in development mode which goes off when i refresh the page.I'm using metal in my rails application which i see could be the reason but not sure if it is the only reason.
Error message on browser:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/2.2.16 (Ubuntu) Server at localhost Port 80
Apache log Error:
[Thu Dec 01 16:55:23 2011] [error] [client 127.0.0.1] Premature end of script headers: view_transactions, referer: http://localhost/admin_portal/1014978061/view_transactions
[ pid=660 thr=3078097552 file=ext/apache2/Hooks.cpp:822 time=2011-12-01 16:55:23.563 ]: The backend application (process 796) did not send a valid HTTP response; instead, it sent nothing at all. It is possible that it has crashed; please check whether there are crashing bugs in this application.
[ pid=796 thr=-608495398 file=utils.rb:176 time=2011-12-01 11:25:23.878 ]: *** Exception NoMethodError in application (undefined method `new' for Rails:Module) (process 796, thread #<Thread:0xb77631b4>):
from /home/brijendra/aptana_studio_3_workspace/wantsa/vendor/plugins/newrelic_rpm/lib/new_relic/control.rb:467:in `new_instance'
from /home/brijendra/aptana_studio_3_workspace/wantsa/vendor/plugins/newrelic_rpm/lib/new_relic/control.rb:54:in `instance'
from /home/brijendra/aptana_studio_3_workspace/wantsa/vendor/plugins/newrelic_rpm/lib/new_relic/agent.rb:167:in `logger'
I would be eager to post any other output if required and also suggestions to fix this issue.
I fixed this error by changing cache as true in my development.rb and it worked fine.