hope someone out there can help me on this one!
Task:
Send xml files to ActiveMQ.
Environments:
Developing:
OS X 10.10.5
node 4.4.3
stompit 0.25.0
Production:
Ubuntu 16.04
node 7.8.0 (tried 4.4.3 too with same results)
stompit 0.25.0
I'm always connecting this way.
var server1 = { 'host': 'activemq-1.server.lan' };
var server2 = { 'host': 'activemq-2.server.lan' };
var servers = [server1, server2];
var reconnectOptions = { 'maxReconnects': 10 };
var manager = new stompit.ConnectFailover(servers, reconnectOptions);
Headers, i set for each frame:
const sendHeaders = {
'destination' : '/queue/name_of_queue',
'content-type' : 'text/plain',
'persistent' : 'true'
};
I'm not allowed to set the content-length header, as this would force the server to interpret the stream as a binary stream.
When connected to the server, i connect to a PostgreSQL server to fetch the data to send.
What works:
var frame = client.send(sendHeaders);
frame.write(row.pim_content);
frame.end();
But it only works at the developing machine. When running this in production environment, the script runs without throwing errors, but never sends the message to the server.
So I tried a different method, just to have a callback when the server receives a message.
var channel = new stompit.Channel(manager);
channel.send(sendHeaders, xml_content, (err)=>{
if(err){
console.log(err);
} else {
console.log('Message successfully transferred');
}
});
Now i get the same results for production and development. It is working as expected, but ...
It only works as long as the body (xml_content) has a maximum length of 1352 characters. When adding an additional character, the callback of channel.send() is never going to be fired.
I'm running out of ideas what to check/test next to get that thing working. I hope someone is reading this, laughing and pointing me to the right direction. Any ideas greatly appreciated!
Thanks in advance,
Stefan
Related
I Used this GitHub repository as a reference. https://github.com/plukkie/WavesLPoSDistributer
In that, config.json file is setup with all the details related to waves node. But' when i'm trying to run the script for collector sessions. I'm facing the socket hangup error. which is due to http request in node address.
Below is the code Which is responsible for generating error:
var getAllAlias = function() {
var AliasArr = [];
var Aliases = JSON.parse(request('GET', config.node + '/alias/by-address/' + config.address, {
'headers': {
'Connection': 'keep-alive'
}
}).getBody('utf8'));
Aliases.forEach(function(alias)
{
AliasArr.push(alias);
console.log(alias);
});
return AliasArr;
}
Any help on this would be great, Thankyou
I'm trying to read in data from an arduino using serialport, and serve it to a web browser.
Without the webserver (ie. if I just leave out that 'listen' call at the end), the serial data gets constantly streamed in with the expected 5 updates per second shown in the console.
But when I add the 'listen' call, nothing is shown on the console until I make a request to the server with my web browser, at which time the console gets at most only one log entry added (but sometimes still nothing).
The data shown in the web browser is the 'old' data from whenever the last request was made, not the current latest data from the arduino. In other words, the serial data is processed a little after each http request is served - not very useful.
const http = require('http');
const serialport = require('serialport');
var serial = new serialport('/dev/ttyUSB0', {
baudRate: 115200
});
var jsonStr = '';
var jsonObj = {};
function handleData(data) {
jsonStr += data;
if ( data.indexOf('}') > -1 ) {
try {
jsonObj = JSON.parse(jsonStr);
console.log(jsonObj);
}
catch(e) {}
jsonStr = '';
}
};
serial.on('data', function (data) {
handleData(data);
});
const app = http.createServer((request, response) => {
response.writeHead(200, {"Content-Type": "text/html"});
response.write(JSON.stringify(jsonObj));
response.end();
});
app.listen(3000);
(The data coming from the arduino is already a JSON string which is why I'm looking for a '}' to start parsing it.)
I also tried using the 'readable' event for getting the serial data but it makes no difference:
serial.on('readable', function () {
handleData(serial.read());
});
If I understand it correctly, the listen call itself is not blocking, it merely registers an event listener/callback to be triggered later. As an accepted answer in a related question says: "Think of server.listen(port) as being kinda similar to someElement.addEventListener('click', handler) in the browser."
If node.js is single threaded then why does server.listen() return?
So why is that 'listen' preventing the serial connection from receiving anything, except for briefly each time a request is served? Is there no way I can use these two features without them interfering with each other?
I discovered that the code worked as expected on a different computer, even though the other computer was using the exact same operating system (Fedora 20) and the exact same version of node.js (v10.15.0) which had been installed in the exact same way (built from source).
I also found that it worked ok on the original computer with a more recent version of Fedora (29).
This likely points to some slight difference in usb/serial drivers which I don't have the time, knowledge or need to delve into. I'll just use the configurations I know will work.
I keep getting the following error response from node when trying to run a read call to rally:
Error: getaddrinfo ENOTFOUND rally1.rallydev.com rally1.rallydev.com:443
I am using the Rally Node SDK, and node v7. I am on a local machine. It is successfully reaching and logging the 'releaseoid' before the 'try'.
I feel like I am not specifying http (which I was before and now completely commented out the server, letting the SDK default it). But it is continuing to give back that error. I could not find (or possibly understand) other general Node guidance that may address this situation. I am not clear where port 443 is coming from as I am not specifying it. Is the SDK adding it?
If I specify the server address without http:
server: 'rally1.rallydev.com',
I still get an error, but this time:
Error: Invalid URI "rally1.rallydev.com/slm/webservice/v2.0null
I am new to Node and not sure if I am having a problem with Node or the Rally Node SDK.
Code below.
var rally = require('rally');
var rallyApi = rally({
apiKey: 'xx',
apiVersion: 'v2.0',
//server: 'rally1.rallydev.com',
requestOptions: {
headers: {
'X-RallyIntegrationName' : 'Gather release information after webhook',
'X-RallyIntegrationVendor' : 'XX',
'X-RallyIntegrationVersion' : '0.9'
}
}
});
// exports.getReleaseDetails = function(releaseoid, result) {
// console.log('get release details being successfully called');
//
//
//
// }
module.exports = {
getReleaseDetails: async(releaseoid) => {
console.log(releaseoid);
try {
let res = await
rallyApi.get({
ref: 'release/' + releaseoid,
fetch: [
'Name',
'Notes',
'Release Date'
]
//requestOptions: {}
});
res = await res;
console.log(res);
} catch(e) {
console.error('something went wrong');
console.log(e);
}
}
}
That mostly looks right. I haven't tried to use async/await with the node toolkit yet- it would be interesting to see if that works. It should, since get and all the other methods return promises in addition to handling standard node callback syntax.
But anyway, I think the issue you're having is a missing leading / on your ref.
rallyApi.get({
ref: '/release/' + releaseOid
});
Give that a shot?
As for the network errors, is it possible that you're behind a proxy on your network? You're right though, https://rally1.rallydev.com is the default server so you shouldn't have to specify it. FYI, 443 is just the default port for https traffic.
I've implemented a server/client implementation of node-ssdp(npm install node-ssdp). Everything "appears" to work but my client does not pick up the server's packet. I am receiving a lot of other payloads from different devices/locations but not the payload from my node-ssdp server.
I'm running on the same machine and I'm running on OSX. I have two separate node projects: one for my client and one for my server.
Note: I've also tried running the server on one machine and the client on a separate machine, in case there was an issue with loopback or something. I also verified via Wireshark that the packets from the server were being read by the client machine. It is sending a NOTIFY * HTTP/1.1 in the headers.
Here are my implementations for client and server:
Server
var SSDP = require('node-ssdp').Server
, server = new SSDP({
location: 'http://' + require('ip').address() + ':33333',
ssdpPort: 33333
})
console.log(require('ip').address())
server.addUSN('upnp:rootdevice')
server.addUSN('urn:schemas-upnp-org:device:MediaServer:1')
server.addUSN('urn:schemas-upnp-org:service:ContentDirectory:1')
server.addUSN('urn:schemas-upnp-org:service:ConnectionManager:1')
server.on('advertise-alive', function (heads) {
console.log('advertise-alive', heads)
// Expire old devices from your cache.
// Register advertising device somewhere (as designated in http headers heads)
})
server.on('advertise-bye', function (heads) {
console.log('advertise-bye', heads)
// Remove specified device from cache.
})
// start server on all interfaces
console.log('starting ssdp server')
server.start()
Client
var ssdp = require('node-ssdp').Client
, client = new ssdp({
})
client.on('notify', function () {
//console.log('Got a notification.')
})
client.on('response', function inResponse(headers, code, rinfo) {
console.log('Got a response to an m-search:\n%d\n%s\n%s', code, JSON.stringify(headers, null, ' '), JSON.stringify(rinfo, null, ' '))
})
client.search('ssdp:all')
// And after 10 seconds, you want to stop
setTimeout(function () {
client.stop()
}, 10000)
I am running out of ideas. It's weird because I've previously implemented a UDP multicast solution and it works. SSDP is, from what I understand, UDP multicast behind the scenes.
From the github issue itself, apparently adding sourcePort to the configuration solved the issue. https://github.com/diversario/node-ssdp/issues/75#issuecomment-292054892
I have been trying to connect to Accumulo from NodeJS through the Thrift proxy, but have been unsuccessful.
var thrift = require("thrift");
var AccumuloClient = require("./AccumuloProxy");
var transport = thrift.TFramedTransport;
var protocol = thrift.TBinaryProtocol;
var connection = thrift.createConnection("localhost", 42424, {
transport: transport,
protocol: protocol
});
var client = thrift.createClient(AccumuloClient, connection);
client.login("root", {'password': "password"});
When I try to login I get
org.apache.thrift.protocol.TProtocolException: Expected protocol id ffffff82 but got ffffff80
Is anyone able to help me out and give me an idea of what I'm doing wrong here?
UPDATE:
I modified protocolFactory line in the proxy.properties file located in Accumulo and restarted the proxy.
protocolFactory=org.apache.thrift.protocol.TBinaryProtocol$Factory
I performed the same steps as above, but added a callback to the createClient call.
var login;
var client = thrift.createClient(AccumuloClient, connection,
function(err, success) { login = success });
This populates the login variable. I then try to use that login variable to execute other functions
client.listTables(login, function(a) { console.log(a) })
results in
{name: 'TApplicationException',
type: 6,
message: 'Internal error processing listTables'}
Trying to create a table
client.createTable(login, "testTable", 1, "", function(a) { console.log(a)})
results in
{name: 'AccumuloSecurityException',
msg: 'org.apache.accumulo.core.client.AccumuloSecurityException: Error SERIALIZATION_ERROR for user unknown - Unknown security exception'}
See answer below.
It turns out that the problem existed because of the handling of the response back from Accumulo. In the AccumuloProxy.js file when the login result is received and read in AccumuloProxy_login_result.prototype.read it will set the success as this.success = input.readString()
The readString() function will take the Buffer and call toString() using the utf8 encoding. This was resulting in characters showing up incorrectly.
I modified the AccumuloProxy_login_result.prototype.read function to set success as this.success = input.readBinary() so that a Buffer is returned. This Buffer can be passed in to the other function calls and will get a correct result back from Accumulo instead of an Exception.
This was put in as an issue with Thrift here and has apparently been fixed in the master branch.
Seems that Accumulo uses the compact protocol, not the binary protocol. It also seems, that there is currently no compact protocol support available for NodeJS.
Please have a look at this SO question as well. It deals with C#, but nevertheless it can be helpful. There are also some solutions out there utilizing RabbitMQ or other message brokers, see here.