I want to design a rounding policy for several components:
// | exchange | type | routing key | queue |
// |--------------|-------|----------------------------|------------------------------|
// | processing | topic | processing.trx.elavon | processing-elavon-sale |
// | processing | topic | processing.trx.elavon | processing-elavon-authorize |
// | processing | topic | processing.trx.elavon | processing-elavon-capture |
// | processing | topic | processing.trx.genesis | processing-genesis-sale |
I tried with Topic exchange and Direct exchange but I get error Reply received after timeout. After investigation it turns out that I'm sending messages to 1 queue but 2 queues are receding messages.
My caseI would like to use routing key and as additional level or abstraction as configuration variable for the target gateway and then to send the type of message to a queue.
But looks like this design is not appropriate.
What routing policy should be more suitable in order to avoid the error: Reply received after timeout? Only one queue should receive the message and reply.
EDIT:
In my case I use Spring AMQP to send messages:
convertSendAndReceive(
ContextServer.EXCHANGE_PROCESSING, ContextServer.ROUTING_KEY_PROCESSING_TRANSACTION_ELAVON, "some_payload");
But how I can reach just one queue processing-elavon-sale, not all queues bind to routing key processing.trx.elavon?
Related
I'm trying to work out how the hexagonal (ports and adapters) architecture might be used in the context of an embedded software system.
if I understand right, the architecture is something like this.
/-----------------\ /-----------------------------\
| | | |
| Application | | Domain |
| | | |
| +----------+ | | +---------+ |
| | +-------------->|interface| | /-------------------\
| +----------+ | | +---------+ | | |
| | | ^ | | Infrastructure |
| | | | | | |
\---------------+-/ | +---+---+ +---------+ | | +----------+ |
| | +---->|interface|<-------------+ | |
Code that allows | +-------+ +---------+ | | +----------+ |
interaction with | | | |
user \--------------------------+--/ \-----------------+-/
Business logic What we (the business)
depend on - persistence,
crypto services etc
Let's take a concrete example of where one of the user interfaces is a touch screen that the main controller talks to over a serial UART. The software sends control commands to draw elements on the screen and the user actions generate text messages.
The bits I see working in this scenario are:
Serial driver
Sends data over the UART
Receives data (an ISR is invoked)
Screen Command builder
Screen Response/Event parser
Business logic such as presenting and responding to menus, widgets etc
The bit I'm struggling with is where these pieces should reside. Intuitively, I feel it's as follows:
Infrastructure - UART driver
Domain - Business logic
Application - Message builder/parser
But this arrangement forces a dependency between Application and Infrastructure where the parser needs to retrieve the data and the builder needs to send the data through the UART.
Bringing the messages builder and parser to Infrastructure or Domain takes the whole user interaction thing away from the Application.
Whichever way I look at it, it seems to violate some aspect of the diagram that I drew above. Any suggestions?
I am currently experimenting with app-events in ktor using Netty. However the only hook that is being called is "ApplicationStarted". What am i doing wrong here?
I set breakpoints in all of the functions, the subscriptions are being made but not all of the event-listeners are invoked.
Also I tried to find some explanation in the ktor docs but that was not successful.
import io.ktor.application.*
fun Application.events(){
environment.monitor.subscribe(ApplicationStarting, ::onStarting)
environment.monitor.subscribe(ApplicationStarted, ::onStarted)
environment.monitor.subscribe(ApplicationStopping, ::onStopping)
environment.monitor.subscribe(ApplicationStopped, ::onStopped)
environment.monitor.subscribe(ApplicationStopPreparing, ::onPrepareStop)
}
private fun onStarting(app: Application){
app.log.info("Application starting")
}
private fun onStarted(app: Application){
app.log.info("Application started")
}
private fun onStopping(app: Application){
app.log.info("Application stopping")
}
private fun onStopped(app: Application){
app.log.info("Application stopped")
}
private fun onPrepareStop(env: ApplicationEnvironment){
env.log.info("Preparing App Stop")
}
"Application started" appears in the log messages but no other output.
How bad am I doing, or is this a bug?
Ok I've been looking into this and found, that the amount of invoked application-level events depend on the server you are using. The following embedded servers support the following events:
+--------+----------+---------+---------------+----------+---------+
| Engine | Starting | Started | StopPreparing | Stopping | Stopped |
+--------+----------+---------+---------------+----------+---------+
| Netty | NO | YES | NO | NO | NO |
| CIO | NO | YES | YES | YES | YES |
| Tomcat | NO | YES | NO | NO | NO |
| Jetty | NO | YES | NO | NO | NO |
+--------+----------+---------+---------------+----------+---------+
Tested on Ktor version 1.1.2
So it currently seems if you want to respond to application stopping events you should use CIO as the server.
EDIT:
CIO does not support HTTPS as of now, so if needed you must stick to one of the other three. However you can use the JVM runtime shutdown hook to raise a stopped event yourself. Beware that the handlers are invoked in a different thread.
private fun onStarted(app: Application){
Runtime.getRuntime()?.addShutdownHook( Thread {
app.environment.monitor.raise(ApplicationStopped, app)
})
app.log.info("Application started")
}
I have two services, Manager and Collector.
Manager is subscribed to Queue COLLECTED_USER with routingKey user.collected and invokes a UserCollected handler.
Collector is subscribed to Queue COLLECT_USER with routingKey user.collect and invokes a CollectUser handler.
There can be multiple collectors so I have set exclusive to false (see below for code).
There are also other services that listen for events like
user.created,
user.updated,
user.deleted
In addition there are services that listen for more general events like
#.created
user.#
and so on.
So I am using a topic exchange.
Setup
| exchange | type | routingKey | queueName |
| -------- | ----- | -------------- | ------------- |
| MY_APP | topic | user.collect | COLLECT_USER |
| MY_APP | topic | user.collected | COLLECTED_USER |
What should happen:
Manager publishes message with routingKey user.collect
Collector gets the user.collect message and invokes a CollectUser handler
Collector's CollectUser handler does work, then publishes a message with routingKey user.collected
Manager gets the user.collected message and invokes the UserCollected handler
What actually happens:
Manager publishes message with routingKey user.collect (correct)
Collector gets the user.collect message and invokes a CollectUser handler (correct)
Manager also gets the user.collect message and invokes the UserCollected handler with the wrong data. (wrong)
Collector's CollectUser handler does work, then publishes a message with routingKey user.collected (correct)
Manager gets the user.collected message and invokes the UserCollected handler (correct)
My Question
Why does the Manager get the user.collect message, given:
It's listening on the COLLECTED_USER queue not the COLLECT_USER queue, and
The Collector, which is listening on the COLLECT_USER queue, has already handled the message.
Implementation details
I create the subscribers and publishers as follows (trimmed for relevance)
Creating a Subscriber
given the AMQP url and params url, exchange, type, routingKey, queueName and handler
const connection = await amqp.connect(url)
const channel = await connection.createChannel()
channel.assertExchange(exchange, type, { durable: true })
const result = await channel.assertQueue(queueName, { exclusive: false })
channel.bindQueue(result.queue, exchange, routingKey)
channel.prefetch(1)
channel.consume(result.queue, handler)
Creating a Publisher
given the AMQP url and params url, exchange, and type
const connection = await amqp.connect(url)
const channel = await connection.createChannel()
await channel.assertExchange(exchange, type, { durable: true })
Publishing
given the channel and params exchange, routingKey, and message
await channel.publish(exchange, routingKey, message)
Note
This question is a follow-on from RabbitMQ — Why are my Routing Keys being ignored when using topic exchange
.
I finally worked out what my problem was. A dirty exchange. While experimenting with this I'd inadvertently added an exchange that was routing messages to the wrong queue, and this was causing my confusion.
To fix it I fired up the RabbitMQ admin GUI and deleted all of the queues and let my code create the ones it needed. There was no issue with the code as outlined above.
I have two kinds of workers for a same event.
I would like a message be dispatched to only one among some of my workers (like "direct" exchanges). But the other workers should all process the message (like fanout).
It's a bit hard to explain but the idea is here. And maybe the following schema will help you to understand what I would like.
Do you have a solution?
Kind regards,
Ben
If I understand you correctly, you would like to have "type-1" as worker where only a single worker work on an item while "type-2" can be treated as multiple handlers (like log-handlers) where all should accept the event.
If i'm right , then you might be able to chain two queues (exchanges) .
exchange1 - fanout - all the "type-2" (loggers) will wait here so they will all get the event
exchange2 - direct - all your "type-1" will wait here so only one will get the event
the trick - you need to make sure that you have a consumer listening on "exchange1" that will also publish to "exchange2".
your best option is to use routing keys with multiple bindings between your exchange and your queues.
i would recommend either direct or topic exchange for this, but not fanout.
to model your example image above, your configuration would look like this:
| exchange | routing key | queue |
|----------|-------------|---------|
| some.ex | type.1 | queue.1 |
| some.ex | type.1 | queue.2 |
| some.ex | type.1 | queue.3 |
| some.ex | type.2 | queue.4 |
| some.ex | type.2 | queue.5 |
basically, you need to have a routing key per queue and a queue per worker.
you may want to read up a bit more on exchanges, queues and bindings, to get a better understanding of when they would be used. i have a few ebooks that cover this (along with other RMQ usage scenarios) at https://leanpub.com/u/derickbailey
I've got three XBees. 2x PROs and a standard, all series 2s.
I've configured one PRO and one standard to be router/endpoints on channel 0 and PAN 234 (this is the default channel and PAN ID when selecting the "XBP24-B"/"XB24-B" "ZNET2.5 ROUTER/END DEVICE AT" profile (version 1247 for both).
However the one PRO I've set with the "ZNET 2.5 COORDINATOR AT" profile has a channel of E (though if I keep flashing the device with the same profile, this changes from 12-F).
Obviously if the coordinator doesn't have the same channel, nothing will work, but I can't see any way of setting the channel manually..?
The CH setting in X-CTU is read only, and I can see any other UI element to change the channel:
I've even been into the terminal and typed (words in brackets are what the terminal returns):
+++ (OK)
ATCH (E)
ATCH0 (ERROR)
ATCH 0 (ERROR)
ATCH00 (ERROR)
ATCH 00 (ERROR)
ATCH E (ERROR)
ATCHE (ERROR)
I've Googled and Googled to no avail. incredibly frustrating, can anyone help?!
I've had them working previous as a matter of fluke as I kept flashing the hardware until the channel numbers match up, but this is obviously ridiculous!
Channel selection with the XBee ZB (S2, S2B, S2C) series of modules works differently than with the XBee 802.15.4 (S1) modules. Channel selection is automatic with ZB (as opposed to it being manual with the 802.15.4 modules).
You normally never need to manipulate the channel selection parameters with ZB. Modules find each other and associate with each other if they can.
If your modules just can't seem to find each other it usually comes down to a mismatch in the PAN settings (ID), security settings (LK), or network joining permission settings on the coordinator (NJ).
Not a lot of information exists on the web outside of the Digi's XBee ZB OEM manual. For reference sake, channel selection with ZB works like this:
XBee ZB Coordinator is powered up
The XBee ZB Coordinator reads its SC parameter and builds a list of candidate channels to scan
The XBee ZB Coordinator then performs an energy scan on each candidate channel
The XBee ZB Coordinator then chooses the channel with the least amount of energy on it
This procedure aims to pick a channel with the least amount of noise on it be it from microwave ovens, WiFi networks, or anything else that might be transmitting on the 2.4GHz frequency band.
Any router or end devices joining a network with consult their SC parameters first, then they will try and search for networks they can join which match their PAN and security parameters. They will join and stay joined to the first network they can--with some minor exceptions (see the JV and NW parameters, for example).
If you want to force a channel selection you must set the SC parameter to enable only a single channel. The SC parameter is a bitmask1. Each bit set in the mask will enable one additional channel. What's tricky about this parameter is that the first bit (bit 0) is not channel 0, it's channel 11 (0x0B). For ease of use, if you wanted to lock an XBee ZB to a single channel here would be the values:
+---------------+---------------+------------------+-------------------------+
| Channel (Dec) | Channel (Hex) | XBee ZB SC Value | XBee Availability |
+---------------+---------------+------------------+-------------------------+
| 11 | 0xB | 0x1 | All |
| 12 | 0xC | 0x2 | All |
| 13 | 0xD | 0x4 | All |
| 14 | 0xE | 0x8 | All |
| 15 | 0xF | 0x10 | All |
| 16 | 0x10 | 0x20 | All |
| 17 | 0x11 | 0x40 | All |
| 18 | 0x12 | 0x80 | All |
| 19 | 0x13 | 0x100 | All |
| 20 | 0x14 | 0x200 | All |
| 21 | 0x15 | 0x400 | All |
| 22 | 0x16 | 0x800 | All |
| 23 | 0x17 | 0x1000 | All |
| 24 | 0x18 | 0x2000 | All |
| 25 | 0x19 | 0x4000 | S1, S2B, S2C (not S2) |
| 26 | 0x1A | 0x8000 | S1 only |
+---------------+---------------+------------------+-------------------------+
Obviously if the coordinator doesn't
have the same channel, nothing will
work, but I can't see any way of
setting the channel manually..?
I'm not sure if what you say above is right. From http://ftp1.digi.com/support/documentation/90000976_C.pdf (you should look at the correct version for your hardware, though), it looks like the purpose of a coordinator is to automatically determine the channel:
Coordinator Operation
Forming a Network
The coordinator is responsible for
selecting the channel, PAN ID (16-bit
and 64-bit), security policy, and
stack profile for a network. Since a
coordinator is the only device type
that can start a network, each ZigBee
network must have one coordinator.
After the coordinator has started a
network, it can allow new devices to
join the network. It can also route
data packets and communicate with
other devices on the network. To
ensure the coordinator starts on a
good channel and unused PAN ID, the
coordinator performs a series of scans
to discover any RF activity on
different channels (energy scan) and
to discover any nearby operating PANs
(PAN scan). The process for selecting
the channel and PAN ID are described
in the following sections.
Channel Selection
When starting a
network, the coordinator must select a
"good" channel for the network to
operate on. To do this, it performs an
energy scan on multiple channels
(frequencies) to detect energy levels
on each channel. Channels with
excessive energy levels are removed
from its list of potential channels to
start on.
I've actually never used the Digi XBee radios (just some of their other radios), so I don't know much about coordinators. I think that their user interface typically does expose all of the valid commands, so it probably won't work to try sending them manually (as you discovered).
You may find more experts on the Digi forums.
Hmm. strange, keep going over the settings again and finally got it working with 2-way comms?! :S
Setup one a coordinator
Setup other two as router/end devices
Set the Device High (DH) to 0 and the Device Low (DL) to FFFF (this means everything sent from this module should be received by everyone)
Set Negotiate Channel to 1 (Enabled), which means the only time a router/end device can set it's own channel is when it finds a coordinator on the same channel (this clearly wasn't happening in my case)
Everything else was left as default.
Leave coordinator powered on when configuring router/end devices so you can check they pair correctly.
As I said, I've used this configuration before and it just didn't work, so I don't know what kicked it into life this time, but it worked?!
One thing to take into account is that ZigBee channels extend from 11 to 26, zero is not a valid option.
Since that's the case, are you able to try the command ATCH11 ?
If that command succeeds, then perhaps the ATCH command wants a decimal input between 11 and 26?