I was reading various resources about netlink, and they all say that the netlink communication protocol is asynchronous (example: https://www.opensourceforu.com/2015/08/netlink-a-communication-mechanism-in-linux/), however this confuses me: I think only events notification mechanism of netlink is asynchronous, while request messages are sent/received synchronously.
Am I wrong?
Related
How can I abort the HTTP Request and not close the connection while implementing a netty HTTP client?
At the moment I am using NioSocketChannel and I am confused if doClose is the only option.
Is there a more generic way of canceling the request, that can work with any kind of socket channel, eg KQueue?
Netty's ChannelFuture extends the netty Future which provides a cancel method: https://netty.io/4.0/api/io/netty/util/concurrent/Future.html#cancel-boolean-
I'm pretty sure that's what you're looking for.
doClose closes the channel where a channel is described as "A nexus to a network socket or a component which is capable of I/O operations such as read, write, connect, and bind." So that would close the connection, as you're seeing. It doesn't look like that's going to help you.
I need asynchronous message sending. I read about non-blocking sending on MPI (e.g. MPI_Isend or MPI_Ibcast) and functions to wait/test that sending request (MPI_Wait*/MPI_Test*). However I realize (through testing and web info) that non-blocking send might never get progress on receiver unless that sender invokes functions MPI_Wait*/MPI_Test* after it sends. How can I get a real (and optimal) asynchronous sending?
Regards
Does the MPI standard implement the request-reply communication pattern?
Reading about MPI I found that there are point-to-point routines like:
Synchronous send
Blocking send / blocking receive
Non-blocking send /non-blocking receive
Buffered send
Combined send/receive
"Ready" send
Maybe a developer can implement the request-reply communication pattern using these routines, but it seems that MPI does not directly implement it.
Edit: For clarifying purposes the request-reply (request-response) is a message exchange pattern in which a requestor sends a request message to a replier system which receives and processes the request, ultimately returning a message in response. This is a simple, but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel. This pattern is especially common in client–server architectures. It may be synchronous or asynchronous.
This is not available as-is.
That being said, this is trivial to implement.
The requestor can MPI_Sendrecv() and the replier can MPI_Recv() the request and then MPI_Send() the answer.
Currently we have a Spring Integration application which accepts HL7 messages. The flow is as follows.
There is a message driven JMS inbound adapter which accepts the messages through ActiveMQ Queue.
Then the message goes through series of transformations and finally ended up in a service activator component to perform necessary business logic.
So far every thing looks good and recently the client requested that they want to have a acknowledgement for each message with the status. There can be two scenarios for a received message
Message executes successfully
Message fails with exception if the required criteria is not satisfied.
So we are thinking of implementing a acknowledgement mechanism which sends the acknowledgement back to the client through the above mentioned ActiveMQ queue or transmit via a tcp port.
Do we have any proven way/ patterns of doing these kind of acknowledgements? Is there any techniques which Spring Integration provides to achive this kind of scenario?
Appreciate your kind reply
Regards,
Keth
See the inbound gateway.
If the sender sets a replyTo header, the reply will be sent there; if not, you can configure a default replyTo destination.
I am reading a bit about the message oriented middleware for SOA. The question which is not clear to me is difference between Instant messaging and Messaging service. Could someone help me to understand this ?
Instant messaging is communication between humans using text messages.
Messaging service is event communication between machines using messages. Those messages are typically packed with information about an event that needs to be processed somehow. There are some pattern commonly implemented by messaging services.
Publish/Subscribe - A publisher sends events to multiple subscribers that can decide what events they want to subscribe to.
Message queue - Messages are sent to a queue used to hold events in a buffer. The messages awaits a consumer to consume messages and process the events. This implements a decoupling in time between systems as well as workload balancing.
Message events typically hold data in some machine readable format, such as XML, JSON, EDIFACT etc.
Another way to look at it: Messaging services can be used to build instant messaging software. The XMPP protocol is an example of that.