I have a network of brokers with the following configuration
<transportConnectors>
<transportConnector name="tomer-amq-test2" uri="tcp://0.0.0.0:61616" updateClusterClients="true" rebalanceClusterClients="true" updateClusterClientsOnRemove="true"/>
</transportConnectors>
I expect that when I connect using the URL
failover:\(tcp://tomer-amq-test2:61616\)?backup=true
the broker shall update th client with the full list of brokers it is conencted too, and the client shall connect to one randomly, and to a second as backup
however this is not happening and the client connects only to the specified broker in the url
help anyone?
Tx Tomer
figured out the problem (at least on my env)
when a broker updates another broker that it is up, it identifies itself by the server name.
once the server name of all brokers was added to /etc/hosts on the client side, all was well
:)
I guess this is bad practice, and the broker should identify itself by ip and not by hostname
I was running activeMQ 5.5.1 on ubuntu 10.4
Your client will only be updated with the full broker-list if some or the following properties are true: updateClusterClients rebalanceClusterClients and updateClusterClientsOnRemove.
you have to set them manually on your client as they are false by default.
see: http://activemq.apache.org/failover-transport-reference.html
Related
Following instructions provided in https://developer.ibm.com/tutorials/mq-jms-application-development-with-spring-boot/, I developed a sample Spring boot web application in order to be able to send and receive messages over IBM MQ using JMS template.
In case of a MQ server not on local host, I updated the application.properties file with:
ibm.mq.conn-name=<my-server-host-name>(<my-server-port>)
Unfortunately this is not the appropriate property as the application is searching for a queue manager on localhost.
I did not find in the documentation anything about the property to use for that. And yes, I gave a try to ibm.mq.host and ibm.mq.port.
For IBM config you need to provide the following properties:
Yml extension:
ibm:
mq:
queueManager: {queueManagerName}
channel: {channelName}
connName: localhost(1415)
user: {UserName}
property extension:
ibm.mq.queueManager={queueManagerName}
ibm.mq.channel={channelName}
ibm.mq.connName=localhost(1415)
ibm.mq.user={userName}
connName you can find in the Listener directory:
In my case IP address is equal: localhost
Port is equal: 1415
channelName you can find in Channels directory.
As per https://github.com/ibm-messaging/mq-jms-spring the default connection properties for mq-jms-spring-boot-starter are
The default attributes are
ibm.mq.queueManager=QM1
ibm.mq.channel=DEV.ADMIN.SVRCONN
ibm.mq.connName=localhost(1414)
ibm.mq.user=admin
ibm.mq.password=passw0rd
You will most likely need to set connName, user and password. The default port is 1414, but if you are running MQ in the cloud then you will need to look up in you cloud what port to use. You will get the port from the same place you look up the server url.
You may also need to supply TLS parameters - https://github.com/ibm-messaging/mq-jms-spring#tls-related-options
You can find sample code here - https://github.com/ibm-messaging/mq-dev-patterns/tree/master/Spring-JMS The 101 sample ( https://github.com/ibm-messaging/mq-dev-patterns/tree/master/Spring-JMS/src/main/java/com/ibm/mq/samples/jms/spring/level101 ) has very little code, so a good test of whether the connection parameters are right.
I have a Mosquitto 2.0.14 broker running in a Windows server 2019. I can connect to it over port 8883 using mqtts protocol with SSL enabled. I can also connect to it on port 1883 without SSL.
Now I want to connect using Websockets. So I added a listener as:
listener 9001
protocol websockets
allow_anonymous false
password_file C:\mosquitto\password.txt
http_dir C:\mosquitto\http_dir
set_tcp_nodelay true
I also tried without http_dir and set_tcp_nodelay. I have tried with and without SSL certificates.
I have port 9001 opened in windows firewall as well as on AWS EC2 instance security groups.
But when I try to connect to the broker using ws://broker.mysite.com:9001 or ws://broker.mysite.com:9001/mqtt nothing happens. No error, no connection. Mosquitto does not show any logs even though I can see the request coming in using WireShark. I am really stuck here. please help me out.
Edit:
I have tried to connect using MQTTX, MQTT Explorer and MQTTBox Chrome App.
As per the comments this issue has been noted previously (in this answer), however I figure its worth repeating here to aid others who experience the problem.
In short - there appears to be a bug in Mosquitto versions 2.0.12, 2.0.13 & 2.0.14 running on Windows when listening for websocket connections. Whilst the broker appears to be listening (on the correct port) it does not, in fact, accept connections (and nothing is logged). I have not investigated in detail but the cause is going to be something about the way the socket is being configured.
There is a workaround - add socket_domain ipv4 under the listener e.g.
listener 9001
protocol websockets
allow_anonymous false
password_file C:\mosquitto\password.txt
http_dir C:\mosquitto\http_dir
set_tcp_nodelay true
socket_domain ipv4
See this issue in the github repo for more information.
I am trying to start my Eclipse Mosquitto broker service for listening to websockets adding:
listener 8083
protocol websockets
at the mosquitto.conf
If I only use listener 8083, the service starts but when protocol websockets is added, the service stops and refuses to start.
The error I get if I run:
mosquitto -v -c mosquitto.conf
is: 1588309602: Error: Unable to start any listening sockets, exiting.
The full output is:
1588309602: mosquitto version 1.6.9 starting
1588309602: Config loaded from mosquitto.conf.
1588309602: Opening websockets listen socket on port 8083.
1588309602: Error: Unable to start any listening sockets, exiting.
I am under Windows10 Pro.
Any ideas?
The answer to this:
Based on trials I can confirm that you need to mention a default port initially e.g.
port 1883
protocol mqtt
# Websockets
listener 9001
protocol websockets
if you only wish to use WebSockets for MQTT then instead of using listener 9001 you need to replace it with port 9001.
There should be atleast one default port to listen to in Mosquitto MQTT.
Verified using Mosquitto 1.6.10
I am posting an answer based on facts.
I have uninstalled version 1.6.9 and installed 1.6.7 and now the service is running using websockets...
I cannot confirm if this is an issue with 1.6.9 but this is what happened to me.
BR
According to other sources, the error lies in 1.6.10 (and perhaps others), whereby, there MUST be a standard protocol mqtt defined, otherwise websockets will not start.
Thus you can leave the standard configuration alone (port 1883) and then in the
Extra listeners section of mosquitto.conf, define the websockets listener as you like.
I believe this has been remedied in later versions, so that only websockets can be defined.
Sadly, in this case the only defense against unauthorized use of the broker over the standard mqtt socket is then the system firewall for external users. Users with ssh access can "play".
The mqtt protocol has to be enabled for the websockets to work.
As the option port (like others have mentioned) is deprecated in versions 2.x.x, you can use listener instead.
listener 1883
protocol mqtt
listener 9001
protocol websockets
And then run your mosquitto server as usual.
i am currently experimenting on websphere MQ 7.5.0, which is used to send message from one machine to another.
I have a server with 2 virtual machines (VM1 and VM2) configured, as well as another standalone laptop. all the machines mentioned above are set using the same ip range (192.168.0.2 -5) and the same subnet, and i turn off the firewall during my experiment.
I follow the ibm website and set up the necessary queue manager, local queues, remote definition and channels. I have success with connecting the laptop to the server, and also from the server to VM1.
however, when i am trying to connect VM1 and VM2 together, after binding, my sender channel is still in retrying status, it means that connection between VM1 and VM2 is not established. I try to ping VM2 using my cmd and i receive all the packets successfully.
what could be the reasons why VM1 and VM2 cannot be connected? Is there any requirement for IBM MQ such that at least one of the MQ must be located in the physical computer?
Thank you everybody in advance!
I would suggest to check the ports that are being used by you VM queue managers and be sure the listeners for those ports are running successfully and not being used by another process.
I just re-installed Ubuntu server 10.04 and decided to change all of my default ports to get a little extra security. Everything works fine, except when I decided to change the FTP (ProFTPd) port from the standard 21 to 3521. No problems with firewalls or port forwarding. ProFTPd was restarted but when I am trying to connect to it,even though it does respond, it throws the client (FileZilla) into a "passive mode" and then never goes into listing a directory.
I don't really want to use the "passive mode" and I have it disabled in proftpd.conf, but nevertheless I can't seem to change the default port otherwise and make it working. It does seem to work fine on port 21. FYI, the proftpd was installed as a standalone daemon, if that matters somehow?
Ok, I think I figured this out after reading this page: link . It appears that most FTP connections are indeed "passive" and the problem with "active" connections comes from the use of firewalls on the client side since FTP server is initiating an outgoing "data" connection to the client on some random port. In passive mode the client initiates both "command" and "data" connections to the server and hence the firewall isn't a problem, but you should specify which "passive" ports to use on the server. I enabled 3520 and 3521 PassivePorts and it's now working
FTP Active Mode by definition requires the server to initiate its outgoing connections from port L-1. Does your firewall allow outgoing connections from port 3520 as well?
From the FTP RFC:
3.2. ESTABLISHING DATA CONNECTIONS
The mechanics of transferring data consists of setting up the data
connection to the appropriate ports and choosing the parameters
for transfer. Both the user and the server-DTPs have a default
data port. The user-process default data port is the same as the
control connection port (i.e., U). The server-process default
data port is the port adjacent to the control connection port
(i.e., L-1).
...
3.3. DATA CONNECTION MANAGEMENT
Default Data Connection Ports: All FTP implementations must
support use of the default data connection ports, and only the
User-PI may initiate the use of non-default ports.
Negotiating Non-Default Data Ports: The User-PI may specify a
non-default user side data port with the PORT command. The
User-PI may request the server side to identify a non-default
server side data port with the PASV command. Since a connection
is defined by the pair of addresses, either of these actions is
enough to get a different data connection, still it is permitted
to do both commands to use new ports on both ends of the data
connection.
You might wish to take the opportunity to change your users to SFTP, a much nicer protocol.