What do you gain by returning Task types from SignalR hub methods, and what are the use cases for doing so?
If you are doing asynchronous operations inside of a Hub method such as DB queries or web requests, it can be more efficient to use the async/await pattern instead of blocking. SignalR will wait for the Tasks returned from Hub methods to complete before sending the unwrapped result back to the calling client. SignalR will also make sure not dispose your Hub until the returned Task completes.
If you are not yet using .NET 4.5, you can use Task.ContinueWith or create your own Tasks using a TaskCompletionSource if you are not working with a Task returning library.
Related
I'm using Retrofit with Reactor Adapter on a server. I thought that it allows me to make my calls unblocking by simple using Mono for retrofit and exposing it to Spring Boot as Mono as well (all operations in between are reactive).
However I noticed that when I try to run a few requests to an another service, that has some long operations inside (taking a few seconds), my service looks like it's blocking some thread, as when making several quick calls in proper configuration it can cause restarting my service (which is supposed to only wait for another service response, and data set it receives is small). Also some tracking tools make me think that my threads are busy when waiting for the response.
I tried to find some docs about that, and looked a bit into OkHttp and Okio code, and I couldn't find any part that could make it non blocking, and what's more it looked like it would be blocking.
Is there something I might miss in my retrofit configuration that could make my calls non blocking, or maybe someone is aware there is no way to make retrofit work this way? Or simply am I misinterpreting some data and it does should be non blocking by default?
I add to my Retrofit builder such setup method to enable Reactor:
addCallAdapterFactory(ReactorCallAdapterFactory.create())
OkHttp follows a roughly thread per connection model. So with a HTTP/2 server a single connection can support a variable number of requests with a fixed set of pooled connections and threads.
call.execute() will be blocking.
call.enqueue(...) will be non blocking but is using threads internally, and reading from the socket in blocking mode. This is hidden from clients, but OkHttp does not use Java NIO.
I try to find some fast algorithm of interprocess communication.
One of I need is an ability to send one command to multiple application instances at the same time. I had tried to find out for a day if I am able to start many instances of the same app (local-rpc-server-app) and call RPC from one client. I use ncalrpc protocol for this purpose.
I just want to start several instances of server and one instance if client, and then call the same RPC func one time on a client to evaluate this RPC func on every running server.
Yes, you can either use multiple client threads (each making a separate server call) or modify the .acf and mark the call with the [async] attribute. If you go the latter route you can then make multiple calls on a single client thread. Note that asynchronous RPC is a fair bit more complicated than synchronous RPC due to needing to deal with call completions.
Making calls to multiple server instances (even local instances) is also made more complicated by the fact that you will have to somehow discover those endpoints, and the RPC namespace functions (RpcNs*) are no longer available as of Windows Vista.
If I want to develop a node.js application for a Hyperledger Fabric Composer business network, it is necessary to define (in the model file) events that are emitted, whenever a transaction takes place. Otherwise, the node.js application is not "informed" about those transactions (see https://hyperledger.github.io/composer/latest/business-network/publishing-events.html).
Defining the events (in the model file ... and emitting them in the respective transaction processor functions) makes it possible for the node.js application to subscribe to those events (and therefore to be informed about transactions happening.)
So far I understand it.
My question is the following:
When I use the composer rest server (i.e. the automatically generated node.js application) instead of developing my "own" node.js application, do I still have to define the events for the transactions defined in the model file (.cto)?
Or is this not necessary because the composer rest server does not use those events anyway?
You would still need to define events in your model, then publish them in your transaction code (and subsequently consume them (subscribe) them from a client - whether composer-client or websockets etc. So regardless of whether you're using the REST APIs, Composer client APIs or even the CLI.
So if you POST a transaction from your REST client (eg. browser)- which sends it to the REST server - you must have defined an event (in your model) AND furthermore, your transaction logic would have to emit that event - for any listener to process it.
What is the difference between PubSub and Methods in Meteor?!
Can I put Methods in Server folder like Publishs?
To me seen like the same, but Methods is more reactive.
They are two different sides of the same coin. Here's a drawing of the data lifecycle in meteor:
Publish - Which data is sent from the server
Subscribe - Which data the client requests publications for
Methods - How to manipulate data from the client on the server
Note - this will typically be run on both on the client and the server. The client will make a prediction as to what the server will do so it can update right away. Then latency compensation will kick in when the method is run on the server and the canonical decision is made.
What is the difference between PubSub and Methods in Meteor?!
Publications are reactive and they provide a cursor. Subscription gets you the matching publication on clientside in a minimongo database. On the other hand, methods must be called instead of subscribed and they are mainly designed to execute server side tasks that you don't want to handle client side for many possible reasons.
More details here for publications: https://www.discovermeteor.com/blog/understanding-meteor-publications-and-subscriptions/
And here for methods:
http://meteortips.com/first-meteor-tutorial/methods/
Can I put Methods in Server folder like Publishs?
Yes you can and you should. For example, put them into server\methods
To me seen like the same, but Methods is more reactive.
This is the exact contrary. They are not the same, even if you can achieve similar results with both. Methods are by design not reactive, and pub/sub are.
I have wrote one sample com server which implements com connection point. I am calling one method in this COM object which in turn calling some other method in my client code using connection point mechanism.
But all the above listed operation is synchronous communication. I would like to make COM server pure async so that if my COM server get some event it should fire the data back to its client.
please suggest how it is possible using COM connection point.
Note :- My COM server is running as a exe out of proc.
Thanks in advance!!!
Regards
Ashish
Threading is never a minor detail in COM, just as it isn't in any runtime environment. You must observe the apartment state that the COM client program selected. And if it is STA, by far the most common selection, then it is your duty to fire the event on the thread that the client code selected. Ignoring that requirement just produces impossible to diagnose bugs in the client program.
So if you fire the event from a worker thread in your own code, the only way to get event handlers to run async, then you must marshal the interface pointer. CoMarshalThreadInterfaceInStream() or the easier-to-use IGlobalInterfaceTable gets that job done. Rock-hard requirement. It will run asynchronously when the client program opted-in by using COINIT_MULTITHREADED when it called CoInitializeEx(). The only thing you can do is publish the fact that your code is thread-safe by picking the ThreadingModel registry value, using "Both" or "Free".
Same as you do it without COM:
the client of your server object calls a method;
the method starts a background operation and returns;
The background operation can use a separate thread, an async I/O API, a timer API, etc. When the background operation has completed, it fires an event (calls a method on the client-provided sink interface);
the client handles the event.
Back to COM, all method invocations in COM are synchronous by default. When you fire an event on the client-provided sink interface, the call will block until the client returns. There's one exception to this behavior: IAdviseSink. The methods of this interface are asynchronous, if the callee resides in a different COM apartment from the caller. However, IAdviseSink is probably not what you're looking for.
The standard way to use asynchronous COM requires that the interface have an separate UUID for the asynchronous interface. IConnectionPoint does not have an async UUID, so you can't use ICallFactory to implement asynchronous COM.