Previously I have setup a device to connect to Google Cloud IoT Core and when the device would connect it would get a callback from the server to a topic with the device configuration file.
I am currently moving off of that to a local MQTT broker on a Raspberry Pi with Mosquitto running. What I am trying to do is figure out how to replicate the sending of the configuration file when connected.
Is there a way for other clients to know when a new client connects? If so I could then just have a client running on the Pi that would is responsible for sending messages.
The thought was that the Pi would hold the configuration file of the connected device and once it connects it would be sent back over to it via a topic for that device
Or is there another solution that I dont even know about yet that accomplishes this? I have not set up my own end to end MQTT communication before so I dont exactly have a path forward here
Is there a way for other clients to know when a new client connects?
Not as part of the protocol; but it's simple enough to publish a message upon connection. I can see a few ways of accomplishing your aim:
Publish all of the configurations as retained messages. You would require a 'config' topic per device for this (say config/uniquedevicename). When the client starts up it will subscribe to the relevant topic and receive its configuration (the 'server' would need to publish a message to each of the config channels with the retain flag set).
Upon starting the device publishes a message requesting its configuration; the server is subscribed to the relevant topic and responds with the configuration. You can use preset topics for the response or pass the topic in as part of the request.
For one (or a small number of devices) option 1 would be very simple to implement; however option 2 provides more flexibility.
Related
I want to implement a chat application which uses "MQTT protocol" in order to send messages from the device(Android phone). I need a "Kafka broker" which would run on the server and listen to these messages.
For this, I need an MQTT proxy, but even after googling a lot I could not find any open source MQTT proxy. Please suggest if there is an open source MQTT proxy. And if not, then, is it possible to implement one of my own?
There is an MQTT Proxy from Confluent, but it is not open source. You can use it free against a single broker, or 30-day trial for a cluster of more than one broker.
Why cannot I run two testAgents(of raspberry pi) at the same time?
When I run them in two separate raspberry pi boards with different deviceIds, when one is connected to the broker other one gets disconnected. Then the next one is connected and 1st gets disconnected... They don't do anything else.
I cannot guess any reason for this and I tried my best to solve this. I tried with same user, different users, same access token, different access tokens. But same thing happened.
They will be using the same MQTT client ID. The broker will always disconnect the first client that connects with a client ID when a second client connects with the same client ID.
The logs from the broker should show this happening.
Here is my use case:
I have two endpoints: one with MQ and the second with TCP/IP
I have to replace a legacy server which accepts queries from remote TCP/IP clients. Once the socket is open with the client, data is exchanged in both sides. the server sends asynchronously MQ data through TCP/IP and receive data from clients asynchronously also. Each data message sent has to be acknowledged. The constraint here is that I have to use the same socket.
I created two routes
from("netty4:tcp://ipAddress:port?sync=true").to("wmq:queue:toQueue")
from("wmq:queue:fromQueue").to("netty4:tcp://ipAddress:port?sync=true")
I start the first queue to receive session open request from clients and then I start the second route to start sending data but I cannot use the same channel.
I tried to get the remote port of the first route and used it in the second route but I have a ConnectException because netty4 tries to open a new socket which is already open.
I found that netty4 can be used asynchronously using the AsyncProcessor but I didn't find any example dealing with my use case.
The only idea I found is that I have to create a standalone server which open the sockets with the clients and make it communicate with the two endpoints.
Is there any way to implement this situation using camel only?
any help on this subject is really appreciated.
Your code won't be able to run as it is for your use case. I also suspect you are trying to use Camel as IP server framework and not an integration in this case.
Lets review Apache Camel's concept of producers and consumers. In the integration world we talk about client and servers as consumers and producers. This might seem like a language difference until you realise a consumer(typically a client) can also be a producer(server).
Some helpful definitions:
1. Producer: A producer is an entity capable of creating and sending a message to an endpoint. A typical example would be code like .to("file:data/outbox") as this produces a file.
2. Consumer: A consumer is an entity that receives messages produced by a producer, it wraps these messages in an exchange and sends them to be processed. A typical example would be code like from(jms:topic:xmlOrders)
A rule of thumb is that typically consumers are the source of the messages being routed.
BIG NOTE:
These two definitions are not set in stone a producer can also be an endpoint using the from and a consumer can be an endpoint using the to.
So in your case let's break up the route:
from("netty4:tcp://ipAddress:port?sync=true").to("wmq:queue:toQueue")
In this route you are creating a Netty server that sends a message to a queue. Here your netty endpoint acts as a consumer(yes it is in the from clause) however this creates a Netty4 Server at the IP address and endpoint you specified. This then send a message to another consumer which is the MQ client which act as a consumer again. So two consumers? Where is the producer? The client connecting to the netty server will act as producer.
Let's look at the second piece of the route:
from("wmq:queue:fromQueue").to("netty4:tcp://ipAddress:port?sync=true")
Here you are creating a client/consumer for the MQ services and then creating a client/producer to the netty server. Essentially you are creating a NEW client here that connects to the SERVER you created in the first route.
So in short your route creates a Netty server that send a message to MQ then creates a MQ client that sends a message to a Netty client which connects to the server you have created. It wont work like this.
Go read about message exchange patterns for further reading, but I would suggest that if you are just using Netty and MQ then maybe Camel is a bit overkill as it is a integration platform and not a IP server platform.
I am aware that the Tibco EMS provides Fault Tolerance in a hot backup configuration on the server side as detailed in the User's Guide, this answer and here.
But on the client side does Tibco EMS provide out of the box solution for fault-tolerant clients?
An example: on the topic Sports.F1.PitStop two clients (server1, server2) register as publishers. The idea being that should something go wrong on server1 (i.e. publisher on server1 goes down), server2 would seamlessly continue to publish on the topic. So the question is, does Tibco EMS provide such client-side fault-tolerance capability?
No.
EMS (or JMS) does not support a client-side fault tolerance feature. The reason is simple : typically, publishers processes don't know each other.
To elaborate:
Topics usually accepts many publishers (more than two).
In a pub/sub scenario, publishers don't know subscribers, and to an extent they don't typically know the other publishers.
Your solution:
My first question regarding your solution: Why can't both servers publish messages at the same time ?
I assume you have a good reason (like messages from server1 and server2 being redundant). In that case, then you will have to have some kind of communication between your "active" and "passive" server.
Possibility 1 : Server2 is connected to a simple service/rmi/other heartbeat mechanism, and can tell if/when Server1 as stopped publishing.
Possibility 2 : Server2 is itself subscribed to the topic, and can tell when messages have stopped.
Last note:
In case you meant shared "subscriptions" (as in, one durable subscription being shared between two servers): the new JMS 2.0 API is supporting this feature. EMS 8 is the only version of EMS supporting JMS 2.0.
I'm not sure if I fully understand your question. EMS is a message broker. It brokers messages. Thats all it does. If you have multiple servers publishing to the same topic, then that is fine for EMS. If your publishers themselves are in a fail-over configuration, so that only one is actively sending and the other takes over when the first one fails, then EMS doesn't care.
Managing the fail-over mechanism from one publisher to the other, that is something you have to develop yourself. EMS doesn't offer anything to support that. You need some kind of mechanism for server2 to know when server1 is down. There are several ways you can do that:
Use a heartbeat mechanism where the active server sends periodical heartbeat messages (possibly across EMS as well) and the passive server listens to them and when they stop, assume server1 is down.
Use an active open connection between server1 and server2 (open a simple tcp port for example and stop it from closing automatically by periodically sending a dummy message), and have an open read on that port. You'll get a connection error the moment server1 goes down and you don't have to wait for timeouts on heartbeats.
Use a third party monitoring tool, such as openview, tivoli or nagios to detect server1 is down and inform server2.
There is a feature on EMS you can use. EMS has system admin topics that you can subscribe to and that log basically anything that goes on internally. You can subscribe to connect and disconnect events to monitor any component connecting to or disconnecting from EMS. If server1 fails, this will be visible as a disconnect event.
heartbeat mecanism:
https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-33918
For example:
client_heartbeat_server=10
client_timeout_server_connection=35
server_heartbeat_client=10
server_timeout_client_connection=35
I am a very beginner to WebSphere MQ world and this is what I'm looking for:
I have to create a simple system with 2 Machine (sender and receiver) to share messages on a queue:
PC 1 sender --> Queue --> PC 2 receiver
Both machines are Windows based and actually are on the same physical PC using virtualbox P1 (host) and PC 2 (guest)
Here is what I have done following online guides:
PC 1 sender:
Websphere MQ (full trial) installed
on MQ Explorer:
Queue Manager "QM.01" created
local Queue "Q.01" created with use=Transmission
channel sender "CH.01" created with queue=Q.01 and some doubts on connection which actually is 1414
PC 2 receiver:
only MQExplorer installed
try to create a remote queue manager with sender IP, 1414 port, and
CH.01 channel --> error 2539 (something wrong on PC 1 configuration
try to create a remote queue manager with sender IP, 1414 port, and
default SYSTEM.ADMIN.SVRCONN channel --> error 4036 (something wrong
with account authentication, I tryed to use the same "Adminitrator#PC
1" user. I've also tried to create the remote queue manager on PC 1
itself with the same result)
I suppose my error could be on PC 1 channel, its icon has a yellow or blue triangle and status=trying are not good.
Ps. forgive me if some setting name are not matching the English version, I have to translate them.
Now that I've been able to configure a remote QMgr on client PC I would learn how to write a simple program (maybe in Java) to read from a queue on the remote queue manager.
I've found a few guides but, before starting in Java, I tried to test amqsget and amqsput from command prompt.
There are no problems from the server machine (with Websphere full trial installed) but the console can't recognize the command from the client (with both Websphere client and MQ Explorer installed)
Where are my mistakes, or what passage have I missed?
When you have an application that needs to talk to a QMgr over the network, you create SVRCONN channels such as SYSTEM.ADMIN.SVRCONN. The application using a SVRCONN channel is able to open queues directly and put or get messages from them. There is no need to create a transmission queue or set USAGE=XMITQ in order for client applications to work.
When you have two QMgrs that need to communicate, you connect them using MCA channels. On the sending QMgr, these include SENDER, SERVER and CLUSTER SENDER. On the receiving QMgr there would include RECEIVER, REQUESTOR or CLUSTER RECEIVER channels. Any of the outbound channels (SDR, SVR or CLUSSDR) require a transmission queue.
In the example you described, there is only one QMgr therefore no SDR, SVR or CLUSSDR channel is required. You will need to use a SVRCONN such as SYSTEM.ADMIN.SVRCONN. You did not mention having defined a listener but apparently you did or else you would not have received a 2539 MQRC_CHANNEL_CONFIG_ERROR message. The reason you get 2539 is because you are attempting to connect with a client to a channel designed for QMgr-to-QMgr connections. The 4036 is because the configuration is incorrect.
Delete CH.01 and redefine it as a SVRCONN channel.
Alter Q.01 with USAGE=NORMAL
Configure WMQ Explorer to connect to CH.01.
As Shashi mentioned, take a look at some of the basic docs. These include...
Introduction to WebSphere MQ
Designing a WebSphere MQ architecture
The Quick Beginnings manuals have been broken up but the main sections are indexed here.
You may also wish to review the WMQ Security Lab for V7.1 and earlier posted at T-Rob.net. Although it is a security lab, it comes with scripts that build the lab environment, including SVRCONN and SDR/RCVR channel pairs, as well as an extensively illustrated lab guide.
Thank you for your response,
Following your indication I've understood I don't need two QMgr as I supposed,
but only one on the sending machine.
Therefore I have changed the query usage to normal, deleted the channel and leave other configuration by default:
SYSTEM.ADMIN.SVRCONN channel and LISTENER.TCP on 1414 port are automatically created.
I've tried also to redefine a channel named CH.01 as a SVRCONN channel
(Channel > new > server connection channel; and then choose between SYSTEM.ADMIN.SVRCONN, SYSTEM.AUTO.SVRCONN or SYSTEM.DEF.SVRCONN)
but unfortunately I wasn’t able to "Configure WMQ Explorer to connect to CH.01".
Anyway every attempt I have made to connect from the second PC are now ended with a AMQ4036 error; even if I’ve set in the CH.01 MCA Properties the ID user as my PC administrator and I have enabled the user identification on PC 2 as administrator#PC 1.
What I'm trying to achieve is to replicate an application used by company which receives data from a remote queue.
The queue connection specification given for test are: Server Name/IP, Port and Channel name.
This is the reason why I'm trying to replicate it creating a QMgr on the receiving PC, because when I tried with the default test information on my company machines it worked creating a QMgr with all the test queues avilable.
I'm now on holiday and I can't have more specific information about my company settings but I hope to be able to replicate a configuration like that.
Regards,
Flavio.