I may have gone crazy... but I am hoping there is a way to do this.
I have a base class that has event handling in it. My console application is running my workflow. Part of that workflow is to raise events at specific intervals in a separate thread to broadcast the workers' current state (a heartbeat I have heard many call it).
I also have another program in the same solution that is a windows form that I want it to be able to listen to what is going on in the console application so that it can display the worker states. I have tried running both at the same time and verified the events are triggering, but the monitor is not finding any of the raised events.
I am fearing that there is no way to do this, and I will need to go to a database logging method or something else... but in the off chance someone knew how to communicate between applications with event (or event-style) logic, I would appreciate it.
Currently the applications are running from the same location. The goal is that the monitor application will eventually be attached with a broadcaster for our network so that our workstations can monitor for certain worker states without being logged into the machine and the main monitor will show us the full status of all the workers.
Please let me know if I need to expand/clarify this, have a 2-year old watching Star Wars while I type this so I may have missed something.
There are several ways: using remoting, custom windows messages and named pipes. One way is How to use named pipes for interprocess communication in Visual Basic .NET or in Visual Basic 2005
Here's a remoting example: Simple Inter-Process Communication In VB.Net
Here an example of custom windows messages: VB.NET, VB6 and C# Interprocess communication via Window Messaging
Perhaps the most 'up-to-date' way is to use WCF Callback Channels: Using Callback Contracts in WCF for Asynchronous Publish/Subscribe Event-Style Communication
Related
We are using Akka.Net and in some cases we need actors to communicate reliably while preserving order over a message queue (i.e. Oracle Advanced Queues or WebSphere MQ, but any message queuing system would work such as RabbitMQ).
We have various requirements why we are using the message queue, so the question isn't if we should be using this with Akka, the question is how.
How would we go about connecting the queue up to Akka so that it is as seamless as possible?
Is a a custom Mailbox the route to go down? Do we need to right a custom IMessageQueue implementation? Or maybe we need a custom router? Are there any specific tests we can run to be sure our Mailbox/IMessageQueue works well with Akka.Net?
EDIT:
Should we maybe looking to implement a custom Transport?
Can any pointers be offered on where to start?
In general implementing custom mailbox based on some reliable queue is not feasible solution - actually it has been already done on the Akka JVM side, and it failed all hopes.
One of the basic reasons is usually the misunderstanding of the basic idea - when people are talking about reliable delivery (that MQ-systems offers), what they really mean, is reliable processing. What if your messages has been send with 100% delivery ratio, but ultimately receiving actor/node has crashed while processing them? From the mailbox point of view everything went smooth...
For this reason, usually the way to go is a dedicated actor - or hierarchy of them - working as a gateway to external messaging system. This way you can not only send message them but also mark them as receive after explicit acknowledgement from successfully completed process. One of the examples may be akka-rabbitmq (written in Scala).
I am getting my head around messaging. Currently we are spiking a few scenarios using Rebus. We are also considering NServiceBus.
The scenario we are trying to build is a proof of concept for a background task processing system. Today we have a handful of backend services hosted in different ways. (web, windows services, console apps) I am looking to hook them up to rebus and start consuming messages using competing consumer, some mesages will have one listener and some will share the load of messages. Elegant :)
I got a pretty good start from this other question How should I set rebus up for one producer and many consumers and it is working nicely in the proof of concept.
Now I want to start reporting progress. My intital approach is to set up pub/sub as well and spin up a service that listens to progress events from all the services. And if a service is interrested in a specific progress in the future it is easy to subscripe of interrest to the messages and start listening.
But how shall I approach setting up both competing consumer and pub/sub? it is dimply two separate things? (In the rebus case one adapter using UseSqlServerInOneWayClientMode / UseSqlServer and another adapter that is set up for the pub/sub using whatever protocol we want?)
Or is there a better solution then having two "buses" here?
I've built something like that myself a couple of times, and I've had pretty good results with using SignalR to report progress from this kind of backend worker processes.
Our setup had a bunch of WPF clients, one single SignalR hub, and a bunch of backend worker processes. All WPF clients and all backend workers would then establish a connection to the hub, allowing workers to send progress reports while doing their work.
SignalR has some nice properties that makes it very suitable for this exact kind of problem:
The published messages "escape" the Rebus unit of work, allowing progress report messages to be sent several times from within one single message handler even though it could take a long time to complete
It was easy to get the messages all the way to the clients because they subscribe directly
We could use the hub groups functionality to group users so we could target progress/status messages from the backend at either all users or a single user (could also be used for departments, etc.)
The most important point, I guess, is that this progress reporting thing (at least in our case) was not as important as our Rebus messages, i.e. it didn't require the same reliability etc, which we could use to our advantage and then pick a technology with some other nice properties that turned out to be cool.
I am trying to figure out the best way to approach this design... Here is some background of what I'm trying to do:
I have a simple digital I/O controller that sends data to my computer via Ethernet. I have a program that can receive this data over Ethernet. I would like a separate front end application that presents this data in a GUI. I am trying to figure out the best way to interface the program that grabs the I/O data over Ethernet, and the program that displays this as the front end. This interface should run whenever the computer boots and constantly poll the I/O in the background.
I've read about Windows Communication Foundation (WCF) and this seems like a nice way to do this. As the windows service would quietly keep polling the I/O and any clients that attach to the WCF interface can present this data in a GUI.
Am I going about this all wrong? Does this seem like a good way to do things? How will my front end clients grab the data from the WCF service?
Thank you in advance.
That's precisely the way I have done it - hosting a WCF service in a Windows service. The Windows service is the process; the WCF service is where the work is done.
In my case, my WCF-based CollectionService is on standby most of the time. I use WCF to start and stop the collector because the WCF programming model makes this easy. However, to get the data from the collector to the UI, I use a TCP socket, not WCF. I know that WCF has a streaming mode, but (1) I've never used it and (2) I believe there is some amount of overhead using WCF this way. The socket is simply a comfortable fallback for me, but I think WCF could be made to work.
If you're just starting, you can refer to these two answers for getting your Windows service up and running using C#. From there, you'll just need to create the ServiceHost and close it in the OnStart() and OnStop() callbacks of your Windows service, respectively.
Easiest language for creating a
Windows service
How to make a
.NET Windows Service start right
after the installation?
If you are new to WCF, take a look at this SO question.
Good and easy books/tutorials to learn WCF latest stuff
One more thing. In the course of your work on this, you may find that you want the WCF service to provide events to your UI when certain things occur. For example, you might provide an event that periodically notifies the UI of the number of bytes that have been received. For this, I would strongly recommend this article by Juval Lowy, one of the WCF gods.
What You Need To Know About One-Way Calls, Callbacks, And Events
His Publish-Subscribe Framework is available for free at his website, IDesign.net, along with several other working WCF examples.
Hope this helps.
I have to design and implement a way to deal with long running processes in a client/server application. A typical long running process would/could take 2-3 minutes. I also need to report progress to the UI in the meantime and keep the UI responsive.
Having these in my mind I though of a few solutions:
One async request to start the process which starts the server-side process and returns an assigned LRPID (Long Running Process ID) then poll periodically from the client using that LRPID. (Pro: simple to deploy, no firewall messing around Con: Unelegant, resource consuming etc.)
Use a duplex binding (such as NetTcpBinding) and initiate callbacks from the server as progress is being made (Pro: Elegant, efficient, Con: Deployment nightmare)
[Your suggestion???]
What would be your take on this?
Here is a post by Dan Wahlin about how to create a WCF Progress Indicator for a Silverlight Application. This should be of some help.
If you do not want to have to worry about the client's firewall, etc... I would probably go with your first solution and use a BackGroundWorker to make the call in order to keep from blocking the UI thread. I did this recently for an app where a request to generate a report is put on a queue and is retrieved once it is done. It seems to work well.
Another way (without having to change the WCF binding) is to use a WebBrowser control in the WPF client, and SignalR to post progress messages from the server to that control.
Note that to avoid javascript errors that happen with the WebBrowser control (because by default it seems to use Internet Explorer version 7 which doesn't seem to be compatible with jQuery.js), you will need to add keys to the registry on the client machine to change the default for the client app to use IE10 or later - see http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version).
This could be a deployment nuisance (because admin rights seem to be needed - eg on a 64 bit Windows 8.1 pc - to add the registry keys).
Also, it still seems necessary to call the long running WCF method in a separate thread, otherwise the WebBrowser control doesn't seem to update its display to show the SignalR messages it is receiving. (This makes sense because the UI thread would otherwise have to wait until the WCF call had finished).
But I mention it as an alternative approach using a newer tool (SignalR) :)
I have a Windows service that's running all the time, and takes some action every 15 minutes. I also have a client WinForms app that displays some information about what the service is doing. I'd like the forms application to keep itself updated with a recent status, but I'm not sure if polling every second is a good move performance-wise.
When it starts, my Windows Service opens a WCF named pipe to receive queries (from my client form)
Every second, a timer on the winform sends a query to the pipe, and then displays the results. If the pipe isn't there, the form displays that the service isn't running.
Is that the best way to do this? If my service opens the pipe when it starts, will it always stay open (until I close it or my service stops)? In addition to polling the service, maybe there's some way for the service to notify any watching applications of certain events, like starting and stopping processing? That way, I could poll less, since I'd presumably know about big events already, and would only be polling for progress.
Anything that I'm missing?
I would steer clear of polling if possible. You're much better off adopting an event-based mechanism, which reduces overhead and provides just-in-time status updates as necessary.
You're already ahead of the curve. WCF is definitely the way to go here for .NET-based applications. And since your form and service are on the same system, the named pipe binding is the one to use as well. Now all you need is to have your service publish events, including periodic status updates, that your form can listen to when it's open.
The easiest way I've found to do this is to use Juval Lowy's Publish-Subscribe Framework. The neat thing about this framework is that it decouples the publisher from the subscriber. The publisher publishes events, not caring if a subscriber is there or not. If a subscriber is present, the event is forwarded for its consumption. Based on your description, I think this would work very well for you.