My QuickFix/n initiator application will be available to multiple threads. Do I need to write logic to deal with concurrent calls to session.Send() or is this handled in the library?
Related
I am building socket web server with Netty 5.0. I came through WebSocketServer example (https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http/websocketx/server).
But I can't understand how to send events to sockets from separate thread. So I have a thread which each second loads some data from external resource. This is StockThread which receives stock data. After receiving data the thread should send events to sockets. What is best practise to do this?
It am using following approach: inside StockThread I store list of ChannelHandlerContext. After receving data I just call write() method of ChannelHandlerContext. So write() method is called from StockThread. Is it okay or there is more appropriate way for this?
Yes, ChannelHandlerContext is thread-safe and can be cached, so this way of usage is completely ok.
See note from "Netty In Action" book, that proves my words:
You can keep the ChannelHandlerContext for later use,
such as triggering an event outside the handler methods,
even from a different Thread.
E.g. I want to call the #Asynchronous fire-and-forget method of service.
Are there any guarantees of "firing" of this method?
What will happen e.g. when server is stopped before actual firing of #Asynchronous method?
Will it be fired on the next start of application?
Is it possible to use other than the thread-pool implementation of #Asynchronous?
Can it act as JMS queue (in persistent way)? Should I use JMS for persistence?
Seems that we can't use #Asynchronous in any reliable system, because it doesn't provide guarantee of firing...
P.S. One possible option is to use persistent Timer's to make deferred calls. Is it good idea?
There are no transactional or persistence guarantees for #Asynchronous methods. I agree that this makes fire-and-forget methods very limited. I do think persistent timers are a reasonable alternative for asynchronously executing work if you need to guarantee it will run.
I am trying to understand implementations/options for server-side Websocket endpoints - particularly in Perl using PSGI/Plack and I have a question: Why are all server-side websocket implementations based around event-driven PSGI servers (Twiggy, Tatsumaki, etc.)?
I get that websocket communication is asynchronous, but a non-event driven PSGI server (say Starman) could spawn an asynchronous listener to handle the websocket side of things. I have seen (but not understood) PHP implementations of Websocket servers, so why cant the same be done with PSGI without having to change the server to an event driven one?
Underlying network logic to deal with sockets depends on platform, OS and particular software implementations.
Most common three methods are:
pulling - there is blocking constant "asking" if socket has some data. This method is well bad, as it will block execution of main thread for as long as it waits for some data.
thread per socket - each new connection involves creating new thread and asking each socket in blocking manner happens within that thread. So it wont block main thread with logic. This method is bad as creating thread for each connection is too expensive for memory, and can be around 1Mb or RAM based on OS and other criteria.
async - uses system features to "notify" your process when there is something. So you can react once your app is ready (in case of single threaded app) or even react in separate thread straight away. This method is well efficient as it saves RAM, and allows your app to work without need of waiting or asking for data. It utilises existing functionalities that most OS and platforms provide.
Taking this in account, you indeed can create single process functional way to deal with sockets traffic. But that is not efficient at all as been proven previously. That is why fully async models are major today, as most languages and platforms do support such paradigm.
I'm trying to setup Canon's EDSDK (for controlling Eos cameras), and it event handlers need to be handled by callbacks via the User32 Get/DispatchMessages api (in Windows at least).
The event dispatching needs to:
loop to continually dispatch messages
happen in the same thread as the SDK is initialised in
This basically requires a single threaded command reciever/message dispatcher thread as can be seen at kritzikratzi's edsdk4j library (the thread is set up in line 66).
So given that Scala has actors that are perfect for recieving messages (from multiple threads, which I could end up doing), what's the best way of going about making a single-threaded access to the Canon sdk and Windows User32 apis?
I'm completely open to (and interested in!) akka if that will help
ASP.NET MVC 2 includes the built in feature of asynchronous controllers. My question is: Is there any benefits on using the asynchronous controllers to send messages to the bus if I'm not waiting for a reply from the bus?
Microsoft states this in their async controller documentation:
In general, use asynchronous pipelines when the following conditions are true:
The operations are network-bound or I/O-bound instead of CPU-bound.
Testing shows that the blocking operations are a bottleneck in site performance and that IIS
can service more requests by using asynchronous action methods for these blocking calls.
Parallelism is more important than simplicity of code.
You want to provide a mechanism that lets users cancel a long-running request.
When reading through the list and keeping in mind that we're not excepting any reply from the bus, I'm not seeing any benefits on using the async controllers over the synchronous ones. But is there?
If you don't need the response then you don't need async controllers.