Two verticles need to send and receive data between them. Is it necessary to have two event bus addresses one for each direction. Or is it possible to have a single vert.x event bus address and send/receive both on the same address.
In vert.x, when you send a message through a eventBus, you can register a replayHandler to receive reply message.
<T> EventBus send(String address,
Object message,
Handler<AsyncResult<Message<T>>> replyHandler)
vert.x send with replyHandler
EventBus is unidirectional.
If you need to send independent messages from A->B and from B->A, you'll have to register two addresses.
I would still recommend against that, since circular dependencies are error prone. Essentially, that's a common recipe for a deadlock. A is waiting for a message from B, while B is waiting for a message from A.
What usually is done in such cases is introducing a broker. That broker will receive all messages, and decided where this messages goes from here. So, instead of A and B holding each an EventBus address, they'll use reply mechanism.
Related
one connection send many request to server
How to process request concurrently.
Please use a simple example like timeserver or echoserver in netty.io
to illustrate the operation.
One way I could find out is to create a separate threaded handler that will be called as in a producer/consumer way.
The producer will be your "network" handler, giving message to the consumers, therefore not waiting for any wanswear and being able then to proceed with the next request.
The consumer will be your "business" handler, one per connection but possibly multi-threaded, consuming with multiple instances the messages and being able to answer using the Netty's context from the connection from which it is attached.
Another option for the consumer would be to have only one handler, still multi-threaded, but then message will come in with the original Netty's Context such that it can answear to the client, whatever the connection attached.
But the difficulties will come soon:
How to deal with an answear among several requests on client side: let say the client sends 3 requests A, B and C and the answears will come back, due to speed of the Business handler, as C, A, B... You have to deal with it, and knowing for which request the answer is.
You have to ensure all the ways the context given in parameter is still valid (channel active), if you don't want to have too many errors.
Perhaps the best way would be to however handle your request in order (as Netty does), and keep the answear's action as quick as possible.
I need atomic broadcast and I want to use akka cluster.
I'm not sure is there atomic broadcast in akka, so I just want to ask, to be sure.
I know, there are such things like DistributedPubSubMediator.SendToAll aswell as Cluster Aware Routers. Does any support total order broadcast ?
By atomic (total order) broadcast I mean, actor A sends broadcast bA aswell as actor B sends broadcast bB (in parallel & from another node). Eventually, (every actor receives message bA before bB) or (every actor receives message bB before bA).
The only ordering guarantee offered by Akka is that messages sent from actor A to actor B will be received in order for that pair of actors. Messages from other actors to actor B could be received before, after or interleaved with the messages from A to B.
So no, Akka does not provide the ordering guarantee you're asking for.
By default there is no such guarantee as messages are sending asynchronously. But you can just use some mediator X (any actor including DistributedPubSubMediator) which will induce such guarantee: send (bA, recipients) from A to X, send (bB, recipients) from B to X, and X should just broadcast every message to its recipients (it will be "atomic" and sequential, as done inside one actor).
If you need to do this in cluster - you could try "Cluster Singleton" to avoid single point of failure by sacrificing high availability and maybe partition-tolerance (you will have to remove nodes manually from the cluster to allow the "P")
I have created an NServiceBus Distributor and Worker, running on separate machines. When I run the worker, it successfully sends a message to the Distributor (and I can see it processed through the Storage queue) but for some reason an output queue is created on the Distributor called
'DIRECT=TCP:xx.xx.xx.xx\PRIVATE$\order_queue$ when the queue should be called
'DIRECT=OS:WORKERDNSNAME\private$\myqueue'.
Does anyone know why the order_queue$ is being created?
Shameless copy direct from an old post at pg2e.blogspot.co.uk:
Transactional queues over HTTP from private networks
When sending messages to a transactional queue over http/s from a
server without a public ip address the ACK-messages may have a hard
time reaching their destination. This is due to the same cause as in
this post (Basically NATting causing a mismatch with the message destination address).
By default the receipts are sent to the sending computers name, which
of course will not work unless both parties resides on the same
network. To fix this you have to map the receipts to the public address
of the sender. This is done by creating an xml-file (of any name) in
C:\WINDOWS\system32\msmq\mapping with the following content.
<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
<setup>
<LogicalAddress>http://msmq.domain.com/*</LogicalAddress>
<StreamReceiptURL>http://[ADDRESS_TO_SENDER]/msmq/Private$/order_queue$</StreamReceiptURL>
</setup>
<default>http://xxx.xx.xxx.xx/msmq/Private$/order_queue$</default>
</StreamReceiptSetup>
Explanation: All messages sent to any queue at msmq.domain.com will
have their receipts sent to the given StreamReceiptURL. The
order_queue$ queue is used to handle transactional control messages.
I suspect later versions of MSMQ or NServiceBus handle creating this queue automatically without you having to create the XML file yourself.
I have been working with qpid and now i am trying to move to broker less messaging system , but I am really confused about network traffic in a Pub Sub pattern. I read the following document :
http://www.250bpm.com/pubsub#toc4
and am really confused how subscription forwarding is actually done ?
I thought zero mq has to be agnostic for the underlying network topology but it seems it is not. How does every node knows what to forward and what to not (for e.g. : in eth network , where there can be millions subscriber and publisher , message tree does not sound a feasible to me . What about the hops that do not even know about the existence of zero mq , how would they forward packets to subscribers connected to them , for them it would be just a normal packet , so they would just forward multiple copies of data packets even if its the same packet ?
I am not networking expert so may be I am missing something obvious about message tree and how it is even created ?
Could you please give certain example cases how this distribution tree is created and exactly which nodes are xpub and xsub sockets created ?
Is device (term used in the link) something like a broker , in the whole article it seemed like device is just any general intermediary hop which does not know anything about zero mq sockets (just a random network hop) , if it is indeed a broker kind of thing , does that mean for pub sub , all nodes in messaging tree have to satisfy the definition of being a device and hence it is not a broke less design ?
Also in the tree diagram (from the link , which consist P,D,C) , I initially assumed C and C are two subscribers and P the only publisher (D just random hop), but now it seems that we have D as the zero mq . Does C subscribes to D and D subscribes to P ? or both the C just subscribe to P (To be more generic , does each node subscribe to its parent only in the ). Sorry for the novice question but it seems i am missing on something obvious here, it would be nice if some one can give more insights.
zeromq uses the network to establish a connection between nodes directly (e.g via tcp), but only ever between 1 sender and 1-n receivers. These are connected "directly" and can exchange messages using the underlying protocol.
Now when you subscribe to only certain events in a pub-sub scenario, zeromq used to filter out messages subscriber side causing unnecessary network traffic from the publisher to at least a number of subscribers.
In newer versions of zeromq (3.0 and 3.1) the subscriber process sends its subscription list to the publisher, which manages a list of subscribers and the topics they are interested in. Thus the publisher can discard messages that are not subscribed too by any subscriber and potentially send targeted messages at only interested subscribers.
When the publisher is itself a subscriber of events (e.g. a forwarding or routing device service) it might forward those subscriptions again by similarly subscribing to its connected publishers.
I am not sure whether zeromq still does client side filtering in newer versions even if it "forwards" its subscriptions though.
A more efficient mechanism for pub/sub to multiple subscribers is to use multicast whereby a single message traverses the network and is received by all subscribers (who can then filter what they wish).
ZeroMQ supports a standardised reliable multicast called Pragmatic General Multicast.
These references should give you an idea how it all works. Note that multicast generally only works on a single subLAN and may need router configuration or TCP bridges to span multiple subLANs.
I'm thinking of creating a generic message queue to handle various inter-process messages. (WCF is not an option at this point.) So, rather than have 10-15 different queues for specific messages I'd have 1 queue that is a 'catch-all'.
Obviously sending messages to this queue is a not a problem. Each recipient would listen to the queue for new messages then 'peek' them, but I'm looking for a clean/efficient way to do this. By clean I mean a method that does not require each and every recipient to read the body of each and every message.
Use System.Messaging.Message.AppSpecific (Integer) to specify a recipient.