I ham running an Artemis broker 2.18 with on all addresses (match="#")
<auto-create-queues>true</auto-create-queues>
<auto-create-addresses>true</auto-create-addresses>
When I start to consume from a non-existing multicast queue using Camel JMS component
from("jms:topic:my_topic")
The generated queue name under the my_topic address is cryptic: 5ae02282-6685-4558-bde4-6bf3dd61c146
I know that I can use FQDN name to properly create it:
from("activemq:topic:my_topic::my_topic")
but this requires changing the client configuration.
Is there a way to configure the broker to use the address name as the default queue name?
In this case that the queue name would be 'my_topic'
I solved this by using the address name of the Artemis multicast queue as the topic name on ActiveMQ.
I query the address name of the multicast queue using jolokia's addressInfo operation
Related
A unique client id having a specific format (d:organizationID:deviceType:deviceID) is used for connection to MQTT in IoT Watson.
It looks that only one unique MQTT connection is allowed per client id to a specific device.
For some cases is required to have more than one simultaneous MQTT connection to the specific device inside the organization account, e.g., in the case of scaling of services integrated with the IBM Watson platform (i.e. clustering).
The question will be, is there the possibility to have more than one simultaneous MQTT connection to the specific device inside the organization account?
For example, by having the possibility to generate a client id or some part of the client id?
It is not possible for devices. The clientId has to be unique as you said and so any existing connection using that clientId would be disconnected when the new connections is made. I am not quite sure I understand the use case you mention with clustering, as the one connection should be fine for a device.
If you have an application rather than a device then you can create a "Scalable Application" as mentioned here https://www.ibm.com/docs/en/watson-iot-platform?topic=applications-communicating-mqtt which extends the clientId.
Is it possible to implement asynchronous request-reply pattern using two JMS message broker instances? Such that service A sends message to queue A, and gets the response from queue B (different broker instance)?
Does JMS API (or Apache Camel) provide some complete mechanism to achieve this transparently with correlation identifiers? What is the necessary configuration?
Bonus question:
To shuffle deck even more, I would like to cluster the queues. Could this be achieved transparently as per specification? Basically I have multiple Spring boot applications (services) with ActiveMQ broker embedded in the Spring context. Each broker acts as an one-way channel for the service, and each service excepts a response for a specific message to other service in it's own broker. Now, I would like run multiple instances of each services and retain the correlation between messages.
Since your request sender (A) and response receiver (B) are two different services - it becomes your responsiblity to store context of original request somewhere.
Probably the easiest is to use a dedicated queue for this purpose (let's call it echo).
(A) could store original request message with some specific correlation Id, for example taken from message Id of request sent. The same correlation Id is supposed to be set for response message, which will be taken by (B). So once response is recieved by (B), it is able to get the original request from echo queue, using selector with the same correlation Id.
Since today we used Camel and ActiveMQ with default JMS and a "org.apache.camel.component.jms.JmsComponent". When consuming a queue like "myJmsComponent:queue:myqueue" , the "JmsDestination" header contains "myqueue".
Now we'd like to use AMQP instead, with "org.apache.camel.component.amqp.AMQPComponent".
When consuming the same queue with "myAmqpComponent:queue:myqueue" the "JmsDestination" header of the message does not contains "myqueue" anymore but a dynamic system name such as "org.apache.qpid.amqp_1_0.jms.impl.QueueImpl#718762d8", and we could'nt find the queue name elsewhere.
How can we retrieve the queue name in such case ?
Seems that you are using an older version which is pulling in the now deprecated AMQP 1.0 JMS client from Qpid so I'd suggest using something more current that uses the supported Qpid JMS client.
The output you are showing seems like the code is just doing a toString on the Destination instance returned from the Message and that object doesn't implement a proper toString so you get the default. You should be using the getQueueName or getTopicName from the destination type returned (Queue or Topic).
My Question centers around this slide from one of Rossen Stoyanchev webinars.
When using a simpleBroker I can send messages to individual users with the /user/** destination format that is picked up in UserDestination and converted. I can also use it to send to a specific session, or all sessions of a specific user.
This is also possible when using an External Broker like ActiveMQ or RabbitMQ as long as the sender is also able to use /user/** or its helper annotations #SentToUser etc.
But, if I am not processing these messages locally and I have another consumer connected to the External Message Broker (Apache Camel for example) How do handle User specific messages and also reply at a user and session level?
If the other consumer is in the same JVM you can have the "brokerMessagingTemplate" bean injected and use it to send messages to user-prefixed destinations.
For 4.2 we plan to support user destinations in a deployment with multiple web application servers connected to an External broker (see https://jira.spring.io/browse/SPR-11620). So if the other consumer is in a different JVM, then you could declare the #EnableWebSocketMessageBroker setup in that JVM as well or you could simple extend AbstractMessageBrokerConfiguration if you don't need the WebSocket client bits.
HTH
I'm new to this forum (at least at asking questions), so please be patient. I'm trying to write simple client-server applications to communicate using datagram (UDP) sockets, with C and Windows.
The scenario is very simple, I want to be able to send/receive data from a machine in some local network (behind a GATEWAY/NAT) to some host having public IP. I can send the data, but it seems impossible to receive any data back, because the remote server can't see the client's local IP.
I don't want the user to perform manual port forwarding on the GATEWAY, and I also don't want to use UPnP because of security issues (though it also should be enabled by the user).
I think it is possible because applications like Skype or Browsers can do it, but how ?
Are there some automatically forwarded ports or things like that ? I'm exhausted of searching the web ... PLEASE HELP !
For UDP connections, most home NAT gateways will automatically create a temporary reverse mapping for each outbound packet.
Consider a scenario where your client is running on the internal machine with IP address 192.168.4.5, sending a UDP packet from port 65000 to the external address 64.34.119.12:6789, via a gateway with external IP address 192.0.43.10. When the gateway sees your internal client send a UDP packet from 192.168.4.5:65000 to the external address, it will NAT it to an external address and port, like 192.0.43.10:5500. Your server will see a packet with a source address of 192.0.43.10:5500 and destination address 64.34.119.12:6789. The router also sets up a reverse mapping, so that if it sees a packet arrive on the external interface with a source of 64.34.119.12:6789 and a destination of 192.0.43.10:5500, it will redirect it back to 192.168.4.5:65000. This mapping typically times out after a short while.
This means that in simple cases, all you need to do is:
On the client, use the same port to send to the server and listen for responses;
On the server, respond to the client at the address and port that the client's packet was receieved from, using the same server port that recieved the packet;
Have the client send the initial packet in the conversation;
Don't leave the "connection" idle for more than a few minutes at a time.