StreamInsight engine as outproc (standalone) and running applications

Question

Hi,

If i want to use SI engine as Standalone (outproc), looks like I need to copy my SI applicaiton Assemblies both in client and server machines?

For example:

SI Server (StreamInsight engine) is running on Machine A

SI Client is running on Machine B, and connected to SI engine running on Machine A using WCF endpoint.

Now I need to copy my SI application assemblies both in Machine A and Machine B. Is it correct? or is there any other way to avoid duplicate copies of the SI application assemblies?

---

Venkat

Answer 1

Other issue with copying the assemblies to Microsoft StreamInsight 1.2\Host location is:
The SI service has to be restarted to recognize the newly copied files !!!
for example, I have one application running (and before starting the SI service, i copied all the assemblies to Host process location).
Now another application wants to use the same Host process, I have to mandatorily stop the service, and copy all the depending assemblies for the new application and start the host process and run the new SI application.
This does not sound good... Any opinion on this based on your experience?

---

Venkat

Answer 2

Yes, you will need to have, at the very least, your adapter assemblies as well as any assemblies containing UD*'s. available to the StreamInsight engine on the remote machine. How else would you run the code on those assemblies? If your query code is in a separate assembly, that won't need to be copied as the queries are fully serialized.

As far as having to restart ... that's a Windows/Framework thing ... even with ASP.NET, if you copy new assemblies to the site, the site is restarted before the changes take effect. ASP.NET does this for you, invisibly, but if you are using something like in-process sessions, those will all go away.

---

DevBiker (aka J Sawyer)
My Blog
My Bike - Concours 14

---

If I answered your question, please mark as answer.
If my post was helpful, please mark as helpful.

Answer 3

About the restart:

I am afraid that, what happens to running queries if abruptly restart the host process?

one thing defintely sure is, I will loose some events which may occur between stop and start of the host process. ASP.NET does restart automatically, but that scenario is quite different, as ASP.NET is designed mainly for stateless applications.. What I was expecting is, SI engine should detect the changes to its folder and load the newly added assemblies at runtime as and when needed.

So we can't really add new SI applications without shutting down the host process.

Could you please let me know:

In what scenarios we can use in-proc?

In what scenarios we can use out-proc?

What are real pros and cons between these differnt hosting mechansims? This will really help me in deciding to choose in-proc or out-proc. So far I was thinking that, out-proc is best, as I can host it on Machine B, and my SI applicaiton (client) can be on Machine A. So machine B is dedicated to SI host process so I was hoping that I can get better perfromance.

---

Venkat

Answer 4

Running queries will have to be shut down, yes. If you use checkpointing, you can keep the state of the queries when it is shutdown. Again ... this is a Windows thing. You simply cannot expect StreamInsight to provide some sort of functionality that simply isn't support by either the operating system or the .NET platform. Would you, for example, expect a WinForms application to just "pick up" changes to a dll that it is using when you replace the DLL?

If your new applications use the same assemblies, you won't have any problem. You can do this if your changes are queries only as the queries are serialized on the wire in a remote scenario. Any changes to adapters or UD*s require code actually loaded from assemblies and running from those assemblies.

Now, as far a your client/server scenario, how do you expect to get the output events to the client? Keep in mind that the adapters run in the server process ... the only way that you'll be able to get the output events to any client application is via an output adapter that sends the events to some cross-process communication mechanism (for example, WCF Duplex or TCP sockets).

The pros and cons are pretty well spelled out in the documentation. StreamInsight in Azure also uses an out-of-process model. From a performance perspective, there's really no difference ... especially since any UI client will need to have some sort of IPC mechanism to get the events (unless the client and server are the same app but then you'd probably have StreamInsight instances everywhere and that's probably not desirable).

---

DevBiker (aka J Sawyer)
My Blog
My Bike - Concours 14

---

If I answered your question, please mark as answer.
If my post was helpful, please mark as helpful.