The JBoss AeroGear JavaScript notifier is a collection of adapters which provide a unified/similar API for interacting with different messaging services and protocols.
Issue
I'm writing some QUnit tests for the JBoss AeroGear JS MQTT over WS adapter which depends on the Eclipse Paho MQTT JavaScript client. The tests work on Firefox/Chrome but fail on PhantomJS 1.9.7 with AMQJS0008I Socket closed connection error.
Initially, my tests were running against an Apache Active MQ broker version 5.9.0 which supports MQTT over WebSockets out of the box. I've also modified them to use the Eclipse Paho MQTT over WebSockets sandbox environment ws://iot.eclipse.org/ws but the problem still exists.
How to reproduce?
Clone my GitHub repository https://github.com/tolis-e/aerogear-js-integration. Checkout the stackoverflow branch, execute npm install and then grunt integration-iot --debug. In order to verify that the tests are working on Firefox/Chrome, open the tests/notifier/mqttws.html in a browser. The QUnit tests are located inside the mqttws.js file. As you can see at the logs below, I'm getting a AMQJS0008I Socket closed error.
Any idea about the error cause? My sense is that the issue is related to the fact that PhantomJS 1.9.7 does not support Web Sockets RFC 6455. It looks like RFC 6455 will be supported by PhantomJS 2.x
Logs
[D] ["phantomjs","qunit.begin"]
[D] ["phantomjs","onLoadFinished","success"]
[D] ["phantomjs","qunit.moduleStart","Connect / Disconnect"]
[D] ["phantomjs","qunit.testStart","Connect to and Disconnect from MQTT Server"]
[D] ["phantomjs","console","Unexpected response code: 404"]
Unexpected response code: 404
[D] ["phantomjs","console","Connection error: AMQJS0008I Socket closed."]
Connection error: AMQJS0008I Socket closed.
[D] ["phantomjs","fail.timeout"]
Related
I'm trying to debug on a live server running a Node.js webserver (Express, TypeScript).
I run the node server with NODE_ENV=development node --inspect=9229 --inspect-brk build/start.js, and it says it's waiting and listening (Debugger listening on ws://127.0.0.1:9229/a61485f2-aef8-4719-901d-4d5ad9d1e6cd).
I set up an SSH tunnel (using this method: https://gist.github.com/pajtai/081e0371e7366c79c0b9), and I set up an "Attach to Node.js/Chrome" debug configuration, with Host: localhost and Port: 9229. Then when I hit the debug button, it connects through the SSH tunnel, and the node.js process runs just fine, stopping and debugging at all my breakpoints.
However, when I don't set up the SSH tunnel, start the node server the same way, and set up an "Attach to Node.js/Chrome" profile with the host as the URL or IP of the server, WebStorm can never connect. There is a little red bubble over the "5: Debug" icon at the bottom saying it can't connect, and sometimes it says "Closed Explicitly". I have opened up port 9229 in the firewall settings for the server (I've tried TCP and UDP).
What am I doing wrong? Please help, anyone!
I'm using Mac OS X 10.15.3 and WebStorm 2019.3.1.
Node binds to localhost by default and thus can't be accessed from outside unless you set up the port forwarding (via ssh tunneling, for example).
You can try changing the command to node --inspect-brk=0.0.0.0:9229 build/start.js - does it help?
Note that Node.js discourages using remote debugging in this way: https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios. Using SSH tunneling is recommended
I have an Angular 6/.NETCore ASP.NET Boilerplate application which uses SignalR to allow the server to execute some client code. The version of the Abp.AspNetCore.SignalR library is 3.5.0-preview3, which uses Microsoft.AspNetCore.SignalR version 1.0.0-preview1.
The SignalR management code is the one shipped in the official template of ASP.NET Boilerplate.
Everything works fine during the development in Visual Studio with IIS Express.
Now I have published the application on a Windows Server 2008 R2, which ships an IIS 7 server. The application starts up but in the Chrome console I see this error:
signalr.min.js:13 WebSocket connection to 'ws://MY-HOSTNAME:21021//signalr failed: Error during WebSocket handshake: Unexpected response code: 400
signalr.min.js:13 Error: Failed to start the connection. undefined
The same problem occurs on Edge:
Starting connection using WebSockets transport abp.js (350,1) Error:
Failed to start the connection. undefined signalr.min.js (13,25649)
SCRIPT12008: SCRIPT12008: WebSocket Error: Incorrect HTTP response.
Status code 400, Bad Request
Here I can see that SignalR is supported in Windows Server 2008 R2, even though it is not supported in IIS 7 (8 is required). It's also written that SignalR is supposed to fallback to some other protocol in case the server does not support WebSocket (my situation).
It is strange that the browser is trying to use the WebSocket protocol, even though it is not supported by the server.
Do you have any clue for this problem? May I be missing something?
UPDATE
I upgraded all the ASP.NET boilerplate libraries to 3.8.1, including the SignalR library.
The error does not show up, so it is a old bug of previous versions.
Now I have this console log:
Starting connection using WebSockets transport
Failed to start the connection: Error: Unable to initialize any of the available transports.
Cannot start the connection using WebSockets transport. Unable to initialize any of the available transports.
Starting connection using ServerSentEvents transport
Information: SSE connected to http://MY-HOST:21021//signalr?asdasdasd
Connected to SignalR server!
Registered to the SignalR server!
So at first it tells that it fails connecting though SignalR with any protocol, but then it succeeds with the ServerSentEvents protocol.
Is it connecting or not?
The version of the Abp.AspNetCore.SignalR library is 3.5.0-preview3, which uses Microsoft.AspNetCore.SignalR version 1.0.0-preview1.
Upgrade to Abp.AspNetCore.SignalR 3.7.0+ (current: 3.8.2) for a stable release version.
So at first it tells that it fails connecting though SignalR with any protocol, but then it succeeds with the ServerSentEvents protocol. Is it connecting or not?
As it says, it is connected using the ServerSentEvents transport. You can see why here:
abp.log.debug('Cannot start the connection using ' + signalR.HttpTransportType[transport] + ' transport. ' + error.message);
if (transport !== signalR.HttpTransportType.LongPolling) {
return start(transport + 1);
}
The error.message ("Unable to initialize any of the available transports.") is a little misleading because only one transport is specified at a time.
Merry Christmas!
I am trying to configure KMS on my Ubuntu 14.04 (64 bit). I could install the KMS server successfully following the guide at https://www.kurento.org/docs/6.0.0/installation_guide.html.
Also, downloaded the Javascript HelloWorld tutorial from https://www.kurento.org/docs/6.0.0/tutorials/js/tutorial-1-helloworld.html. I could run the example successfully on localhost on Google Chrome Version 47.0.2526.106 (64-bit) on the same Ubuntu System.
But, I could not see the local video nor the loop backed video. Only a spinner icon is shown on both the Video placeholders. Consulting the Console log reveals a problem after creating the SDP offer. The error is as described below.
kurento-client.js:21072 WebSocket connection to 'wss://127.0.0.1:8433/kurento' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
I am no expert on web sockets and stuff. Any help on this would really help me to proceed forward.
Note: I am running the example on HTTP, not on HTTPS. I guess that would not be the cause of the problem, though.
Regards,
LazyCoder7
I managed to solve it. I was wrong on my guess though, HTTPS was indeed required in order to make the WebSocket connection ( i was not aware of that part ). Created a certificate file (.pem) (from crt and key file already in the helloworld folder) and configured the KMS server to use the certificate. After this I was able to see myself and the same me in loopback :)
You are following an old version of the documentation. Since Chrome 47, in is mandatory to server pages through HTTPS if you want to use the getUserMedia APi. So we updated all our tutorials, and they now have a self-signed certificate. In case of the JS tutorials, you also need to configure KMS to expose a secure WS signalling connection, as the browser directly connects to the media server to control it.
Please follow the latest version of the documentation here
Be sure that the KMS is running on the port 8433 (not 8888), if you are using docker
docker run -d --name kms -p 8433:8433 kurento/kurento-media-server:trusty-latest
I am trying to use Paho's JavaScript library to connect to a Mosquito MQTT server. I have just used the example on the Paho website. Which is:
function onConnect() {
console.log("onConnect");
client.subscribe("harleyRowland/myTopic");
message = new Paho.MQTT.Message("Hello");
message.destinationName = "harleyRowland/myTopic";
client.send(message);
}
onConnect();
On Safari, I get the following error:
Error: AMQJS0011E Invalid state not connected.
and on Chrome, I get the following error as well as the one above:
WebSocket connection to 'ws://mosquitoServer.co.uk:1883/mqtt' failed:
Error during WebSocket handshake: net::ERR_CONNECTION_RESET
I need to use the Mosquito server for this work. Is it possible using JavaScript? If it isn't possible, is there another web technology I could use?
You need to add a websockets listener to your mosquitto setup. you do this by adding something like the following to your mosquitto.conf
listener 1884
protocol websockets
This will listen for MQTT over websockets on port 1884 (not 1883 as you can not run both on the same socket with mosquitto).
You will also need to be running mosquitto newer than 1.4 and not on Windows unless you compile it yourself
I'm trying to connect the Mongo shell with Mongolab. I am using my mongolab username and password but it is giving an error: "Failed to connect to 54.81.180.188:56789."
My userName and password is correct.
I'm using Windows 8.1
When I ping ds0-----.mongolab.com that's working fine.
C:\mongodb\bin>mongo ds0----.mongolab.com:56789/dbname -u "MyUserName" -p "MyPassword"
MongoDB shell version: 3.0.3
connecting to: ds027751.mongolab.com:56789/dbname
2015-06-05T10:55:30.019+0530 W NETWORK Failed to connect to 54.81.180.188:56789, reason: errno:10061 No connection could be made because the target machine actively refused it.
2015-06-05T10:55:30.024+0530 E QUERY Error: couldn't connect to server ds027751.mongolab.com:56789 (54.81.180.188), connection attempt failed
at connect (src/mongo/shell/mongo.js:181:14)
at (connect):1:6 at src/mongo/shell/mongo.js:181
exception: connect failed
I had the same problem, my server abruptly lost the ability to connect to MongoLab. I contacted support, who sent this reply:
Hello,
Your Experimental Sandbox plan is running MongoDB 3.0.x, which
includes changes to Mongo's authentication mechanism. This new
mechanism is supported by certain newer driver versions, as described
at
http://docs.mongodb.org/manual/release-notes/3.0-scram/#upgrade-drivers.
To connect to this database, you will need to use one of the drivers
listed at the above link.
Please let us know if you have questions about this.
Sincerely, Samson
I assume I was upgraded automatically, as I hadn't touched the server code or MongoLab in months. As an immediate fix, I just created a new db in MongoLab, which was created in mongod v2.6.9 (I don't remember seeing an option to choose the version).