What is the best npm library to make ActiveMQ calls from nodejs? I've tried 'stomp' but sometimes it acts wired.
Whenever I use stomp port (61613) it worked
but when I use tcp port (61616) it throws an exception in ActiveMQ logs saying packet size is max out.
The behavior you describe as "weird" is the behavior I would expect. The listener on port 61616 in ActiveMQ 5.x is for OpenWire clients and therefore not suitable for STOMP clients. If you use a STOMP transportConnector then you shouldn't have any problem.
Related
I have a JAVA api which needs to consume data from ActiveMQ.
Client has provided me the host,Port and API key details.
Im a newby in this ActiveMQ and need suggestion on how to establish the initial queue connection since the queue works on tcp protocol.
I was suggested to use one of the client libraries supported by activeMQ in various languages
Currently i am referring : http://activemq.apache.org/cross-language-clients.html
Need suggestion on how to configure or execute (if i use "How to Send a Message to an Apache ActiveMQ Queue with Node.js" from the above link) on the below code.
const stompit = require('stompit');
stompit.connect({ host: 'localhost', port: 61613 }, (err, client) => {
const frame = client.send({ destination: 'SampleQueue' });
frame.write('Simples Assim');
frame.end();
client.disconnect();
});
Assuming i don't have any Node environment setup in my machine.
If the endpoint that is exposed to you is using the standard TCP based endpoint for the broker then you need to use a client that connects via the TCP layer using the OpenWire protocol which is the native protocol for the ActiveMQ JMS client and the C++ ActiveMQ-CPP client as well as the NMS.ActiveMQ .NET client. You cannot use a STOMP client or other protocol client to talk directly to an OpenWire TCP transport connector.
You can listen to or send messages to ActiveMQ using the STOMP protocol. Just use the example from https://github.com/gdaws/node-stomp
(and you definitely need to install Nodejs on the machine that will be running that script).
I'm not sure of how your workflow is with the Java API, but if that API sends some message to ActiveMQ and you need to deal with that message, you can use stompit. All you need to do is subscribe to the queue in which the message is stored. If you need to send a reply message, you can do so as well to any queue you wish.
For example socket.io has pingInterval and pingTimeout settings, nes for hapi has similar heartbeat interval settings. This is ostensibly to prevent any intermediates such as over-zealous proxies from closing what seems to be an inactive connection.
But ping/pong frames are part of the websocket protocol and seem to serve the same purpose. So why do websocket library implementors add another layer of ping/pong at the application level?
If I was pushed to guess it would be in case the websocket server is dealing with a client that doesn't respond/support the websocket protocol level ping-pongs.
I did some reading up and made some tests and I think it comes down to this:
Websocket pings are initiated by the server only
The browser Websocket API has isn't able to send ping frames and the incoming pings from the server are not exposed in any way
These pings are all about keepalive, not presence
Therefore if the server goes away without a proper TCP teardown (network lost/crash etc), the client doesn't know if the connection is still open
Adding a heartbeat at application level is a way for the client to establish the servers presence, or lack thereof. These must be sent as normal data messages because that's all the Websocket API (browser) is capable of.
The requirements of the project are:
If any user updates a record (any record), all relevant parties must be notified immediately by displaying an alert somewhere in the webpage. In previous projects, the browser would poll the server for any relevant changes every N seconds.
I have been reading on web sockets and think this is the prefect solution for this problem (I do not like polling).
I have some questions regarding Web Sockets in JavaEE. Please correct me if I am wrong.
Web Socket seems to be supported on Glassfish server not in latest version of JBoss/Wildfly.
If 1000 clients are logged in and connected to the server using Web Socket, does the server have 1000 separate sockets open for each connection? Or is the implementation similar to Node.js where a single server socket is used for all client connections. This information does not seem to be documented anywhere in JavaEE tutorials.
Websockets are TCP connections and the websocket protocol is simply an upgrade of the TCP protocol with an handshake procedure similar to the http protocol, but the websocket protocol is bidirectional.
I don't think you are getting a single web socket in Node.js. You have a connection per logged client anyway. In Node.js you have the broadcast, but this is the same as sending a message to any logged client through the related web socket. You have the same functionality in glassfish, where you simply loop on all the web sockets:
http://www.byteslounge.com/tutorials/java-ee-html5-websockets-with-multiple-clients-example
and you can do the same in weblogic:
https://docs.oracle.com/middleware/1212/wls/WLPRG/websockets.htm#WLPRG872
This is the same as Node.js without any wrapper.
I have to support a GPS devices that writes to a socket and at the same time websockets from suppose a mobile device. Can the same socket.io code support both of these?
Short answer : no such module for socket.io to call or serve TCP requests doesn't exist .
Long answer : you can easily solve this in your node.js by working with this possible options
First option would be to just support socket.io all the way client
and server. So you can easily develop with one protocol.
Second option is to combine socket.io + TCP server, and handle
received requests with the same handler. To simplify take this as an
example for server-side.
// run socket.io server
// run TCP server
function Handler(event,data,socket){
this.getProfileData=function(data,socket){
// things to do
// call socket.emit for socket.io ,or socket.write for TCP
}
this[event](data,socket); // call appropriate event
}
// when receiving a new message from either socket.io or TCP
new Handler(event,data,socket);
Third option is to use a bridge such as WebTCP or implement your own bridge.
There is also experimental TCP socket API for browsers, but its not recommended.
I have made my personal project using WebSocket.
I already know that WebSocket will not connect directly raw TCP Socket.
so, I have thought what if I connect, at first, to Web Server(NodeJS) and then switch to TCP server.
is It possible to switch connection to another server using NodeJS?
If so.
Please let me happy.. Thank you! have a nice day.
I would assume it might be both possible and straightforward to tunnel/proxy TCP traffic. The high level design would be:
Start up a web server with integrated websocket server (use socket.io, really)
When a client makes a websocket connection, create an upstream TCP connection to your target server
Then do full bidirectional piping of messages between the browser<->node socket and the node<->otherServer socket
Devil might be in the details. I haven't tried, but seems feasible.
There's a node project called ws-tcp-bridge as well as a python project that claim to do this already. Neither luke terribly mature, but they might just work or at least provide good reference material.