I have a proxy that reads a message from a queue and, using only a business, I must put the message iteratively in four topic.
I can't use a Xquery with topic endpoint because I have different environments and this endpoints are different in any environment.
It's possible to use Split-Join with JMS?
Thank's!!
Split-joins are a parallel alternative to ForEach loops, so if you could do it in an (unrolled) ForEach loop, then you can do it in a SplitJoin.
Related
I am newbee in message broker area . Currently there are quiet a good no. of message broker are there(Rabbit-mq ,zeromq ,kafka and many more).
Want to know which thing to consider while opting for any message broker for backend architecture .
Route messages to one or more of many destinations
Transform messages to an alternative representation
Perform message aggregation, decomposing messages into multiple messages and sending them to their destination, then recomposing the responses into one message to return to the user
Interact with an external repository to augment a message or store it
Invoke Web services to retrieve data
Respond to events or errors
Provide content and topic-based message routing using the publish–subscribe pattern
https://en.wikipedia.org/wiki/Message_broker
Try to use RabbitMq, simple and fast.
Simplified... We are using NServiceBus for updating our storage.
In our sagas we first read data from our storage and updates the data and puts it back again to storage.The NServicebus instance is selfhosted in a windows service. Calls to storage are separated in its own assembly ('assembly1').
Now we will also need synchronous read from our storage through WCF. In some cases there will be the same reads that were needed when updating in sagas.
I have my opinion quite clear but maybe I am wrong and therefore I am asking this question...
Should we set up a separate WCF service that is using a copy of 'assembly1'?
Or, should the WCF instance host nservicebus?
Or, is there even a better way to do it?
It is in a way two endpoints, WCF for the synchronous calls and the windows service that hosts nservicebus (which already exists) right now.
I see no reason to separate into two distinct endpoints in your question or comments. It sounds like you are describing a single logical service, and my default position would be to host each logical service in a single process. This is usually the simplest approach, as it makes deployment and troubleshooting easier.
Edit
Not sure if this is helpful, but my current client runs NSB in an IIS-hosted WCF endpoint. So commands are handled via NSB messages, while queries are still exposed via WCF. To date we have had no problems hosting the two together in a single process.
Generally speaking, a saga should only update its own state (the Data property) and send messages to other endpoints. It should not update other state or make RPC calls (like to WCF).
Before giving more specific recommendations, it would be best to understand more about the specific responsibilities of your saga and the data being updated by 'assembly1'.
My app has multiple threads that publish messages to a single RabbitMQ cluster.
Reading the rabbit docs: i read the following:
For applications that use multiple threads/processes for processing, it is very common to open a new channel per thread/process and not share channels between them.
And I understand that instead of opening multiple connection (expensive)
it is better to open multiple channels.
But why not use a single channel to all threads?
What are the benefits of using multiple channels over a single channel?
AMQP has the concept of Channel to provide more flexibility over reliable TCP connections. Opening a TCP connection per message would be extremely expensive, so they came up with the idea of logical Channels within a connection.
It is not a good idea to use a Channel for all the threads because if anything fails in a particular thread and the Channel dies, the rest of the threads will throw the exception AlreadyClosedException. A channel can die for multiple reasons: for example for trying to declare something that is already declared with other parameters or trying to cancel a consumer which doesn't exist, publishing to an exchange that doesn't exist, etc...
My best advice would be to have an object that holds a Channel in a local variable and also implements ShutdownListener interface, so every time the channel fails, it is able to recover and create a new one from a connection. So I would say that the main benefit is failure tolerance and scalability, since if a Channel dies it won't affect the rest.
We use a windows service based on NServiceBus.Host to handling certain type of messages (say Message A) which are sent from some web services (messages are used as commands). In the future we want to update our services and introduce new type of messages (say Message B).
Is it possible in case of single queue to configure endpoints in old and new version of the windows service that each will handle only messages it knows about (old version - only Message A, new version - only Message B) and leave in the queue all the rest?
If it's impossible then a obvious solution is to have own queue for each type of message and I suppose own endpoint for each queue. Okay, let's assume we want to support in the future not only new messages (Message B) but also old (Message A). Are there ways to implement this (multiple endpoints) in scope of single host process or single way is using two host processes (accordingly two windows services) for each endpoint?
Thank you.
The nice thing about NServiceBus it's support for inheritance. If you have a look at the documentation I think you will find what you are after.
http://particular.net/articles/messages-as-interfaces
There is also a detailed example on http://particular.net/articles/versioning-sample
While
ConnectionFactory.newConnection(Address[] addrs)
and thus
ConnectionFactory.newConnection(
Address.parseAddresses("somehost.com:5672,otherhost.com:5672"))
work, I was wondering if there was a way to pass multiple URIs like:
ConectionFactory.newConnection("amqps://somehost.com:5671,amqps://otherhost.com:5671")
Or to allow potentially different client certificates for each URI, first create multiple ConnectionFactories, each with one URI and then create a ConnectionFactory that takes those connection factories as inputs.
Pretty sure this is not possible. http://www.rabbitmq.com/uri-spec.html
If you are trying to implement failover, you might consider something like heartbeat: https://wiki.archlinux.org/index.php/Simple_IP_Failover_with_Heartbeat
If you are trying to read messages from multiple places, you can use shovel (http://www.rabbitmq.com/shovel.html) to bring these messages from multiple places into one queue and read from that.