-
Sharing objects between application instances using WCF
[This is the sequel to Sharing objects between application instances (using .NET Remoting)]
Well, it took me some time to get back to this - there's a lot to read about WCF. And as I think this one will be mainly about WCF from now on, I've started a new thread about it.
After having read lots of stuff about WCF and getting an idea of what it can all do and a vague idea of how I make it doing that, I decided to first translate the "greetings" sample from A Developer's Introduction to Windows Communication Foundation 4 from C# to C++/CLI to use it as an easy toy for initial experiments:
Code:
// WcfTest1Server.cpp: Hauptprojektdatei.
// Translated from C# sample code at http://msdn.microsoft.com/en-us/library/ee354381.aspx
#include "stdafx.h"
#using "System.ServiceModel.dll"
using namespace System;
using namespace System::ServiceModel;
using namespace System::ServiceModel::Description;
[ServiceContract]
public interface class IHello
{
[OperationContract]
void SayHello(String ^name);
};
[ServiceContract]
public interface class IGoodbye
{
[OperationContract]
void SayGoodbye(String ^name);
};
public ref class GreetingService : public IHello, public IGoodbye // Service implements both contracts
{
public:
virtual void SayHello(String ^name)
{
Console::WriteLine("Hello {0}", name);
}
virtual void SayGoodbye(String ^name)
{
Console::WriteLine("Goodbye {0}", name);
}
};
int main(array<System::String ^> ^args)
{
// Host is configured with two base addresses, one for HTTP and one for TCP
ServiceHost ^host = gcnew ServiceHost(GreetingService::typeid,
gcnew Uri("http://localhost:8080/greeting"),
gcnew Uri("net.tcp://localhost:8081/greeting"));
host->Open();
for each (ServiceEndpoint ^se in host->Description->Endpoints)
Console::WriteLine("A: {0}, B: {1}, C: {2}", se->Address, se->Binding->Name, se->Contract->Name);
Console::WriteLine("Press <Enter> to stop the service");
Console::ReadLine();
host->Close();
return 0;
}
That was easy so far. :)
Difficulties started, however, when I tried to write a client for it, which I assumed not to be much more challenging either. And then it already took me some time to figure out that svcutil only accepts my server .exe as input if I compile it at least with the option /clr:pure instead of the mere /clr that gets set up by default by the IDE for a console app (unlike a Windows Forms app, BTW). (That does imply I can't use native code in a WPF service, doesn't it?)
Then, after I had the .h file generated by svcutil, I tried to compile my minimalistic client with that header. (I don't post the client code itself for now since I'm sure it's irrelevant: The compiler already stalls while processing the .h file.) I get a bunch of C3766 errors, telling me I'd better implement the add/remove accessors of the five events inherited from ICommunicationObject, like void System::ServiceModel::ICommunicationObject::Closed::add(System::EventHandler ^). I get these errors for the two client classes HelloClient and GoodbyeClient which derive from ClientBase<TChannel> with the respective interface as the type parameter.
However, according to MSDN, already ClientBase<TChannel> does implement them, yet these implementations are private. So what? :confused:
I renamed the header file from its original name schemas.microsoft.com.2003.10.Serialization.h, which I found too long and somehow looked to me like svcutil would name all these files like that anyway, to WcfTest1Client.h, but I don't think that can have such consequences, can it?
I'm confident I'll eventually figure this out, but there seems to be a considerable learning curve ahead. So, any help is appreciated. :)
-
Re: Sharing objects between application instances using WCF
Though WCF stuff can be implemented in C++/CLI, I think it is much better to make it in C# and connect to your existing application using class library. You can save a lot of efforts by using C#.
BTW, according to my experience, WCF is one of W*F series that really works and has a good performance.
-
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
That does imply I can't use native code in a WPF service, doesn't it?
Not sure... What if you isolate the native code, and create a .NET-only wrapper around it?
Quote:
Originally Posted by
Eri523
I get a bunch of
C3766 errors, telling me I'd better implement the add/remove accessors of the five events inherited from
ICommunicationObject, like
void System::ServiceModel::ICommunicationObject::Closed::add(System::EventHandler ^). I get these errors for the two client classes
HelloClient and
GoodbyeClient which derive from
ClientBase<TChannel> with the respective interface as the type parameter.
However, according to
MSDN, already
ClientBase<TChannel> does implement them, yet these implementations are private. So what? :confused:
Those are events (on the MSDN page), not getters/setters - I'm a little rusty on C++/CLI equivalent of C# properties, but that's most likely what it wants. I know C++ .NET had some clumsy syntax for properties, and I think they changed it to something more intuitive in C++/CLI. Basically, the service contract is defined via the attributes (ServiceContract, OperationContract, DataContract, DataMember). The DataMember attribute is, in C# WCF model, applied to properties (which are syntactic sugar for get/set methods; nevertheless, note that functions are marked with the OperationContract attribute, but properties are a part of the data contract and have the DataMember attribute).
As for svcutil, i don't think it's really required: it's purpose is (among other things I guess) to take a service, obtain the WSDL - which specifies the service contract, and use it to create a skeleton for a (potentially 3rd-party) client app.
Something like this:
But, since you created the service, you know the contract, so, I think that in effect you can skip that and create a test client manually. On the other hand, it would be nice to make it all work as it's supposed to... Because some other developer should be using the WSDL to create a client on his end.
Anyway, I hope that makes sense, and I wish I could be of more help.
-
1 Attachment(s)
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Alex F
Though WCF stuff can be implemented in C++/CLI, I think it is much better to make it in C# [...]. You can save a lot of efforts by using C#.
Mostly out of curiosity (you know, I'm somewhat neophobic about languages... :rolleyes:), what would I gain by making that transition? I suspect that workflow-style way of creating services, which sounds like one could click them together without writing a single line of code, isn't supported by C# Express anyway.
Quote:
[...] and connect to your existing application using class library.
You mean I would use (or provide) a client-side DLL that exposes my services interface (or perhaps any application-specific adaption of it I want) and encapsulate interaction with the actual service? If yes, I think that DLL would, in most cases, just be an ultra-thin wrapper around the .h file generated by svcutil. As you'll see below, I got my test client, employing that .h file, to work in the meantime. The client .cpp file actually is just 26 code lines, and essentially there's nothing else in the client app besides that and the mentioned .h file. (I must admit, however, that of course this particular client is quite primitive, as is the service.)
Quote:
BTW, according to my experience, WCF is one of W*F series that really works and has a good performance.
Good news, glad to hear! :)
Quote:
Originally Posted by
TheGreatCthulhu
Not sure... What if you isolate the native code, and create a .NET-only wrapper around it?
Actually an idea I alredy thought about myself. It would certainly not be enough to isolate it in a separate module. As it's the assembly (i.e. .exe file) svcutil operates on and complains about, it'd need to be isolated in a separate DLL. So bye-bye to the monolithic one-.exe app I like so much. But then again, if the app is accompanied by its own server it's not that monolithic anymore anyway...
At any rate, I probably won't need any native code in the project this is eventually meant to be used in at the moment. So these considerations are rather hypothetic...
Quote:
Those are events (on the MSDN page), not getters/setters[.]
Actually, I was already concerned about using the term "accessors" in this context when I was writing the post (I somehow anticipated a reaction like yours from anyone... :)) but I couldn't think of a better one. :o
Quote:
I'm a little rusty on C++/CLI equivalent of C# properties, but that's most likely what it wants. I know C++ .NET had some clumsy syntax for properties, and I think they changed it to something more intuitive in C++/CLI.
add() is mapped to operator+=, remove() to operator-= and Invoke() to operator(). Not too clumsy I'd say. (And they are no propertes... :p)
Quote:
Basically, the service contract is defined via the attributes (ServiceContract, OperationContract, DataContract, DataMember). The DataMember attribute is, in C# WCF model, applied to properties (which are syntactic sugar for get/set methods; nevertheless, note that functions are marked with the OperationContract attribute, but properties are a part of the data contract and have the DataMember attribute).
Though I wouldn't have sworn on it in my last post, it turned out that neiter the service contract nor the operation contract was the problem. As to the data contract: There's none involved here (or is there an implicit one regarding the String parameter?). And though it's encouraged all the way to use properties in .NET, I still mostly prefer explicit method calls over properties when an operation beyond a simple data transfer is involved, which obviously is the case when communicating with a service. And if it is a plain data transfer, I'll likely use plain public data members (perhaps due to the lacking notion of trivial properties in C++/CLI).
Quote:
As for svcutil, i don't think it's really required: it's purpose is (among other things I guess) to take a service, obtain the WSDL - which specifies the service contract, and use it to create a skeleton for a (potentially 3rd-party) client app.
[...]
But, since you created the service, you know the contract, so, I think that in effect you can skip that and create a test client manually.
Actually, my main reason to use svcutil here was to create a starting point, since I didn't yet come across any relevant samples of how to create a client.
Quote:
On the other hand, it would be nice to make it all work as it's supposed to... Because some other developer should be using the WSDL to create a client on his end.
Actually, I do have a WSDL that was produced as an intermediate step. I created the WSDL from the .exe and then the .h from the WSDL, both steps using svcutil. As I understood the svcutil documentation, there's no direct way from an .exe to a .h. However, I only had a brief look into the WSDL since I knew I wouldn't need to work with it directly.
Quote:
Anyway, I hope that makes sense, and I wish I could be of more help.
Oh, it certainly did. And of course, as we all know, it's usually more productive to discuss things rather than exchanging ready-to-use solutions.
So here's the client I have at this stage. Actually, it's just the same one I had as of my last post. It was only the .h file (and the app-config file, but I'd find that out later) that caused problems.
Code:
// WcfTest1.cpp: Hauptprojektdatei.
#include "stdafx.h"
#include "WcfTest1Client.h"
using namespace System;
int main(array<System::String ^> ^args)
{
String ^strName;
Console::Write("Please enter your name: ");
strName = Console::ReadLine();
HelloClient ^helloclient = gcnew HelloClient;
helloclient->SayHello(strName);
helloclient->Close();
GoodbyeClient ^goodbyeclient = gcnew GoodbyeClient;
goodbyeclient->SayGoodbye(strName);
goodbyeclient->Close();
#ifdef _DEBUG
Console::WriteLine("Hit <Enter> to continue...");
Console::ReadLine();
#endif
return 0;
}
I mentioned in my last post that I had problems with the compiler demanding implementation of these five events. The solution I found for that feels pretty hackish but at least it works for now: I simply added dummy events to the client classes. Here's, exemplarily, HelloClient:
Code:
[System::Diagnostics::DebuggerStepThroughAttribute,
System::CodeDom::Compiler::GeneratedCodeAttribute(L"System.ServiceModel", L"4.0.0.0")]
public ref class HelloClient : public System::ServiceModel::ClientBase<IHello^ >, public IHello
{
public:
HelloClient();
HelloClient(System::String^ endpointConfigurationName);
HelloClient(System::String^ endpointConfigurationName, System::String^ remoteAddress);
HelloClient(System::String^ endpointConfigurationName, System::ServiceModel::EndpointAddress^ remoteAddress);
HelloClient(System::ServiceModel::Channels::Binding^ binding, System::ServiceModel::EndpointAddress^ remoteAddress);
virtual System::Void SayHello(System::String^ name) sealed;
// It insists on having implementations of the events, so I give it five dummies
public:
virtual event EventHandler ^Closed;
virtual event EventHandler ^Closing;
virtual event EventHandler ^Faulted;
virtual event EventHandler ^Opened;
virtual event EventHandler ^Opening;
};
Adding the events and a bit of reformatting to the two client classes was all I changed about the .h file. I just hope I didn't cut off something important in the private event implementations inside ClientBase<TChannel> with my dummy events.
I'm uncertain about what the IHelloChannel and IGoodbyeChannel declared in the .h file are for. I couldn't find any references to them in the entire project code, and they're empty anyway except for the two interfaces they inherit. Could they be referenced implicitly from somewhere?
Also important, of course was the app.config file created by svcutil, stored under the default name output.config. I could leave it uncanged except for adding the address attributes to the two endpoint nodes:
Code:
<client>
<endpoint binding="basicHttpBinding" bindingConfiguration="DefaultBinding_IHello"
contract="IHello" name="DefaultBinding_IHello_IHello" address="http://localhost:8080/greeting" />
<endpoint binding="basicHttpBinding" bindingConfiguration="DefaultBinding_IGoodbye"
contract="IGoodbye" name="DefaultBinding_IGoodbye_IGoodbye" address="http://localhost:8080/greeting" />
</client>
I have attached a ZIP file containing the client files (.cpp, .h and app.config) as well as the original .h and app.config files generated by svcutil for reference.
One thing I don't really understand yet is tempuri.org. Right from the start I regarded it a mere placeholder for a real address (which got confirmed by the three-line Wikipedia article), so I replaced the four instances of it in the .h file with localhost:8080, but it turned out that the placeholder is referenced by default at some points inside the server which made connection attempts fail. I could make it work by simply reverting back to tempuri.org in the .h file, but of course I need to find out how to correctly set up the server instead.
Next step I'll take will probably be implementing the data sharing scenario from the Remoting thread with WCF.
-
Re: Sharing objects between application instances using WCF
If you need interprocess communication on the same computer, the best way is to use pipe and not HTTP. I don't remember details, take a look at NetNamedPipeBinding class. The change is transparent and affects only application configuration file.
-
Re: Sharing objects between application instances using WCF
Thanks. That confirms thoughts I already had. For the first experiment I just wanted to connect to the given server, but I'll certainly look into NetNamedPipeBinding and aim to implement the sharing test scenario based on that.
-
Re: Sharing objects between application instances using WCF
Ok, as an intermediate step I decided to first modify the greeting sample to use the netNamedPipeBinding which turned out to be easier than expected. The only thing I needed to change about the C++/CLI code was the statement in the server that instantiates the service host:
Code:
ServiceHost ^host = gcnew ServiceHost(GreetingService::typeid,
gcnew Uri("net.pipe://localhost/greeting"));
The rest could actually be done by modifying the app.config files. I removed anything or at least most of which isn't really needed and now have WCF use default values. This is the server's app.config (it didn't have one before):
Code:
<configuration>
<system.serviceModel>
<services>
<service name="TestServer.GreetingService">
<endpoint address="net.pipe://localhost/greeting"
binding="netNamedPipeBinding"
contract="IHello" />
<endpoint address="net.pipe://localhost/greeting"
binding="netNamedPipeBinding"
contract="IGoodbye" />
</service>
</services>
</system.serviceModel>
</configuration>
And this is the client's one which is considerably shorter now:
Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<client>
<endpoint binding="netNamedPipeBinding"
contract="IHello" name="DefaultBinding_IHello_IHello" address="net.pipe://localhost/greeting" />
<endpoint binding="netNamedPipeBinding"
contract="IGoodbye" name="DefaultBinding_IGoodbye_IGoodbye" address="net.pipe://localhost/greeting" />
</client>
</system.serviceModel>
</configuration>
However, now I'm facing some uncertainties about how to implement the test scenario form the Remoting thread using WCF. The central question is: How would I return a live object (the TestServer::Server instance in the Remoting model code) using WCF? I found it was pretty straightforward using Remoting by deriving the class in question from MarsharByRefObject but I didn't yet come across anything equivalent in WCF. Does WCF have something like that at all, and if yes, where?
In the meantime I'm considering an alternative approach that simply avoids returning a live object to the client: Drop the factory class and make the server class a singleton by specifying [ServiceBehavior(InstanceContextMode=InstanceContextMode::Single)] (what AFAIK isn't possible at all when using Remoting which led to the introduction of the factory class in the first place). The main role of the original Server class is now assumed by a new class internal to the server of which the new singular exposed server instance is able to manage multiple instances. (Remember the original scenario this is meant to be used for in the real-life app.) The clients now simply submit requests to send mails by calling a server method, the rest happens invisibly inside the server app.
This alterative approach feels a bit less OO to me, but perhaps it's more client/server style and certainly it provides a higher level of encapsulation. Any comments?
-
Re: Sharing objects between application instances using WCF
Eri, check out my CG Tray Notify article series.
It uses a WCF service hosted from a Windows Service application to communicate with a Tray Icon app running by different logged on users.
It also uses two-way binding to send events to the tray icon clients.
-
Re: Sharing objects between application instances using WCF
Arjay, thanks for pointing me to those articles. :) They were quite instructive, in particular part III of course. And your design with the singular exposed server object holding a number of Folder instances resembles the design I plan to use in my real-life app to a surprising extent.
Some things pointed out in your articles clarified things I've read on MSDN, while others made me question some things I thought I had understood about WCF. In particular this one: Does setting the InstanceContextMode of my service contract implementation to Single really extend its lifetime to the entire time the hosting ServiceHost remains open? IOW is the lifetime of an instance of the service class not subject to be limited by any of the WCF standard timeouts under these circumstances? In that case I'd need to implement my own "self destruction mechanism" since I want my service instance and in turn the server app instance to auto-shutdown a certain time after the last client instance has detached. And I'm currently uncertain how to do that.
I see, however, two differenes between our two scenarios that don't let it look reasonable to make my server a Windows Service: My service instance is neither meant to be shared between distinct users, nor to outlive the last client instance by a really significant timespan.
And, mainly out of curiosity: Are all the project and class templates you use in the articles, in particular the one for a Windows Service, actually supported by the C# Express Edition as well?
Right now I'm working on the WCF implementation of my test scenario and I think it'll be ready for posting about tomorrow. And it'll probably be a bit more refined than the one from the Remoting thread, i.e. more inclined towards the real-life scenario.
-
2 Attachment(s)
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
Right now I'm working on the WCF implementation of my test scenario and I think it'll be ready for posting about tomorrow. And it'll probably be a bit more refined than the one from the Remoting thread, i.e. more inclined towards the real-life scenario.
Ok, it took a bit longer, but here it is. :) And it is at least one step further from the Remoting implementation. It's about 30% more code than that, but that's not due to increased complexity in handling WCF, rather a result of much more functionality being implemented. In particular it now has its own timeout mechanism, since I now think what I need can't be implemented based on WCF's own timeout mechanism with reasonable effort. Actually, from a framework design perspective this is already pretty close to how I plan it for the real-life app, however, of course it doesn't have any noticable business logic.
Here's the header and implementation files of the core server class and a few helper classes:
Code:
// Server.h (Test Server)
#pragma once
#using "System.ServiceModel.dll"
namespace TestServer
{
using namespace System;
using namespace System::Threading;
using namespace System::ServiceModel;
using namespace System::Collections::Generic;
private enum class ClientMirrorStatus { Active, Detached, TimedOut };
private ref class ClientMirrorImage
{
public:
ClientMirrorImage(int nInstanceNumber, Timers::Timer ^tmrHeartbeat);
void AssertActive(bool bResetTimeout);
void Detach();
bool IsActive();
virtual String ^ToString() override;
private:
void HeartbeatHandler(Object ^sender, Timers::ElapsedEventArgs ^e);
void DetachFromHeartbeat();
private:
initonly int m_nInstanceNumber;
Timers::Timer ^m_tmrHeartbeat;
int m_nTimeout;
ClientMirrorStatus m_status;
};
[ServiceContract(SessionMode=SessionMode::Required)]
public interface class ITestServer
{
[OperationContract]
int GetClientInstanceNumber();
[OperationContract]
String ^GetSharedData(int nInstanceNumber);
[OperationContract]
void SetSharedData(int nInstanceNumber, String ^strData);
[OperationContract]
void Detach(int nInstanceNumber);
};
[ServiceBehavior(InstanceContextMode=InstanceContextMode::Single)]
public ref class Server : public ITestServer
{
public:
Server();
~Server();
// Service contract interface method implementation prototypes
virtual int GetClientInstanceNumber();
virtual String ^GetSharedData(int nInstanceNumber);
virtual void SetSharedData(int nInstanceNumber, String ^strData);
virtual void Detach(int nInstanceNumber);
internal:
static bool Startup(Action ^dltShutdownRequestCallback, Action<int> ^dltStatusReportCallback);
static void Shutdown();
static int GetServerObjectCount();
static array<String ^> ^GetInstanceInfo();
static bool IsPrimaryServerInstanceIdle();
private:
bool IsIdle();
array<String ^> ^GetInstanceInfoCore();
void HeartbeatHandler(Object ^sender, Timers::ElapsedEventArgs ^e);
private:
static EventWaitHandle ^s_evtServerLaunched = nullptr;
static Action ^s_dltShutdownRequestCallback = nullptr;
static Action<int> ^s_dltStatusReportCallback = nullptr;
static ServiceHost ^s_host = nullptr;
static int s_nServerObjectCount = 0;
static Server ^s_svrPrimaryServerInstance = nullptr;
int m_nClientInstance;
String ^m_strSharedData;
List<ClientMirrorImage ^> ^m_lstClientRegistry;
Timers::Timer ^m_tmrHeartbeat;
int m_nTimeout;
};
}
Code:
// Server.cpp (Test Server)
#include "StdAfx.h"
#include "Server.h"
using namespace System::Runtime::CompilerServices;
using namespace TestServer;
// ClientMirrorImage methods
ClientMirrorImage::ClientMirrorImage(int nInstanceNumber, Timers::Timer ^tmrHeartbeat) :
m_nInstanceNumber(nInstanceNumber), m_tmrHeartbeat(tmrHeartbeat), m_nTimeout(60000), m_status(ClientMirrorStatus::Active)
{
tmrHeartbeat->Elapsed += gcnew Timers::ElapsedEventHandler(this, &ClientMirrorImage::HeartbeatHandler);
}
[MethodImpl(MethodImplOptions::Synchronized)]
String ^ClientMirrorImage::ToString()
{
String ^str = String::Format("Client #{0}\t{1}", m_nInstanceNumber, m_status);
if (m_status == ClientMirrorStatus::Active)
str += String::Format(", timeout {0} seconds", m_nTimeout / 1000);
return str;
}
[MethodImpl(MethodImplOptions::Synchronized)]
void ClientMirrorImage::HeartbeatHandler(Object ^sender, Timers::ElapsedEventArgs ^e)
{
if (m_status == ClientMirrorStatus::Active && m_nTimeout > 0) {
m_nTimeout -= m_tmrHeartbeat->Interval;
if (m_nTimeout <= 0) {
m_status = ClientMirrorStatus::TimedOut;
DetachFromHeartbeat();
}
}
}
void ClientMirrorImage::DetachFromHeartbeat()
{
if (m_tmrHeartbeat) {
m_tmrHeartbeat->Elapsed -= gcnew Timers::ElapsedEventHandler(this, &ClientMirrorImage::HeartbeatHandler);
m_tmrHeartbeat = nullptr;
}
}
// Asserts that the object is active and optionally resets the timeout
[MethodImpl(MethodImplOptions::Synchronized)]
void ClientMirrorImage::AssertActive(bool bResetTimeout)
{
if (!IsActive())
throw gcnew InvalidOperationException(String::Format("Attempted to access inactive ClientMirrorImage object (#{0})",
m_nInstanceNumber));
if (bResetTimeout)
m_nTimeout = 60000;
}
void ClientMirrorImage::Detach()
{
DetachFromHeartbeat();
if (IsActive())
m_status = ClientMirrorStatus::Detached;
}
bool ClientMirrorImage::IsActive()
{
return m_status == ClientMirrorStatus::Active;
}
// Server methods
Server::Server() : m_nClientInstance(0), m_strSharedData(String::Empty),
m_lstClientRegistry(gcnew List<ClientMirrorImage ^>), m_tmrHeartbeat(gcnew Timers::Timer(1000)), m_nTimeout(60000)
{
if (!s_svrPrimaryServerInstance) s_svrPrimaryServerInstance = this;
Interlocked::Increment(s_nServerObjectCount);
m_tmrHeartbeat->Elapsed += gcnew Timers::ElapsedEventHandler(this, &Server::HeartbeatHandler);
m_tmrHeartbeat->Start();
}
Server::~Server()
{
Interlocked::Decrement(s_nServerObjectCount);
}
array<String ^> ^Server::GetInstanceInfo()
{
return s_svrPrimaryServerInstance ? s_svrPrimaryServerInstance->GetInstanceInfoCore() :
gcnew array<String ^>{"No server object instantiated yet"};
}
[MethodImpl(MethodImplOptions::Synchronized)]
array<String ^> ^Server::GetInstanceInfoCore()
{
List<String ^> ^lst = gcnew List<String ^>;
String ^str = "Server\t";
if (IsIdle()) {
if (m_nTimeout > 0)
str += String::Format("Idle, timeout {0} seconds", m_nTimeout / 1000);
else {
str += "TimedOut";
if (s_dltShutdownRequestCallback) str += ", shutting down...";
}
} else str += "Active";
lst->Add(str);
for each (ClientMirrorImage ^cmi in m_lstClientRegistry)
lst->Add(cmi->ToString());
return lst->ToArray();
}
bool Server::IsIdle()
{
if (!m_lstClientRegistry->Count) return true;
int i = 0;
while (i < m_lstClientRegistry->Count && !m_lstClientRegistry[i]->IsActive()) ++i;
return i >= m_lstClientRegistry->Count;
}
bool Server::IsPrimaryServerInstanceIdle()
{
return !s_svrPrimaryServerInstance || s_svrPrimaryServerInstance->IsIdle();
}
[MethodImpl(MethodImplOptions::Synchronized)]
void Server::HeartbeatHandler(Object ^sender, Timers::ElapsedEventArgs ^e)
{
if (IsIdle()) {
if (m_nTimeout > 0) {
if ((m_nTimeout -= m_tmrHeartbeat->Interval) <= 0 && s_dltShutdownRequestCallback)
s_dltShutdownRequestCallback->BeginInvoke(nullptr, nullptr);
}
} else m_nTimeout = 60000;
}
int Server::GetServerObjectCount()
{
return s_nServerObjectCount;
}
// Service contract interface method implementations
int Server::GetClientInstanceNumber()
{
m_lstClientRegistry->Add(gcnew ClientMirrorImage(++m_nClientInstance, m_tmrHeartbeat));
if (s_dltStatusReportCallback) s_dltStatusReportCallback(Thread::CurrentThread->ManagedThreadId);
return m_nClientInstance;
}
String ^Server::GetSharedData(int nInstanceNumber)
{
if (s_dltStatusReportCallback) s_dltStatusReportCallback(Thread::CurrentThread->ManagedThreadId);
m_lstClientRegistry[nInstanceNumber - 1]->AssertActive(true);
return m_strSharedData;
}
void Server::SetSharedData(int nInstanceNumber, String ^strData)
{
if (s_dltStatusReportCallback) s_dltStatusReportCallback(Thread::CurrentThread->ManagedThreadId);
m_lstClientRegistry[nInstanceNumber - 1]->AssertActive(true);
m_strSharedData = strData;
}
void Server::Detach(int nInstanceNumber)
{
m_lstClientRegistry[nInstanceNumber - 1]->Detach();
}
// To be called upon start-up of the supposedly singular primary server .exe instance,
// returns true if no other instance is running yet, i.e. the "launched" event was not set:
bool Server::Startup(Action ^dltShutdownRequestCallback, Action<int> ^dltStatusReportCallback)
{
EventWaitHandle ^evt = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
if (evt->WaitOne(0)) {
evt->Close();
return false; // Start-up failed: primary instance already running
}
s_evtServerLaunched = evt;
s_dltShutdownRequestCallback = dltShutdownRequestCallback;
s_dltStatusReportCallback = dltStatusReportCallback;
s_host = gcnew ServiceHost(Server::typeid, gcnew Uri("net.pipe://localhost/TestServer"));
s_host->Open();
evt->Set();
return true;
}
// To be called upon shutdown of the singular server .exe instance:
void Server::Shutdown()
{
if (s_evtServerLaunched) {
s_evtServerLaunched->Reset();
s_evtServerLaunched->Close();
}
if (s_host) s_host->Close();
}
I have kept the basic design with the server start-up and shutdown methods, but there's a bunch more things happening between these two invocations now. As before, everything regarding the server begins in the server app's main form class' constructor and ends in its destructor:
Code:
public:
Form1(void) // Test Server
{
InitializeComponent();
//
//TODO: Konstruktorcode hier hinzufügen.
//
if (Server::Startup(gcnew Action(this, &Form1::ServerShutdownRequestCallback),
gcnew Action<int>(this, &Form1::ServerStatusReportCallback)))
{
timer1->Start();
} else {
Text += " (non-primary)";
MessageBox::Show("There's already an instance of the server running. Please use that.",
Text, MessageBoxButtons::OK, MessageBoxIcon::Exclamation);
}
lblGuiThreadId->Text = String::Format("GUI thread ID: {0}", Thread::CurrentThread->ManagedThreadId);
}
protected:
/// <summary>
/// Verwendete Ressourcen bereinigen.
/// </summary>
~Form1() // Test Server
{
timer1->Stop();
Server::Shutdown();
if (components)
{
delete components;
}
}
I'd say the implementation file of that form is rather unspectacular, so I leave it out here. But of course it's contained in the attached project.
The two main differences to the Remoting implementation, from the client point of view, are that the client now handles starting up the server app if needed mostly independent of the server itself, and that the client now keeps the client instance number obtained from the server and uses it as a handle to identify itself to the server when invoking its methods later. These are c'tor and d'tor of the client's main form:
Code:
public:
Form1(void) // Test Client
{
InitializeComponent();
//
//TODO: Konstruktorcode hier hinzufügen.
//
lblGuiThreadId->Text = String::Format("GUI thread ID: {0}", Thread::CurrentThread->ManagedThreadId);
bool bClientObjectValid = false;
try {
EventWaitHandle ^evt = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
if (!evt->WaitOne(0)) { // This means the server isn't running yet, so start it
Process ^proc = Process::Start(Path::Combine(Application::StartupPath, "TestServer.exe"));
Trace::Assert(proc != nullptr, "WCF Share Test: Failed to launch TestServer");
Trace::Assert(evt->WaitOne(10000), "WCF Share Test: Wait for TestServer start-up timed out");
proc->Close();
}
evt->Close();
m_client = gcnew TestServer::TestServerClient;
m_nInstanceNumber = m_client->GetClientInstanceNumber();
Text += String::Format(" #{0}", m_nInstanceNumber);
}
catch (Exception ^e) {
MessageBox::Show(String::Format("Client object instantiation or server connection failed: {0}", e),
Text, MessageBoxButtons::OK, MessageBoxIcon::Error);
groupBox1->Enabled = false;
}
}
protected:
/// <summary>
/// Verwendete Ressourcen bereinigen.
/// </summary>
~Form1() // Test Client
{
if (m_client && m_client->State != CommunicationState::Faulted) {
m_client->Detach(m_nInstanceNumber);
m_client->Close();
}
if (components)
{
delete components;
}
}
The implementation file of this form class is big-time boring so I omit that as well.
The two app.config files aren't really thrilling either, but they're essential to the operation of the client/server pair and they're pretty short, so here's TestServer.exe.config:
Code:
<configuration>
<system.serviceModel>
<services>
<service name="TestServer.Server" behaviorConfiguration="debug">
<endpoint address="net.pipe://localhost/TestServer"
binding="netNamedPipeBinding"
contract="TestServer.ITestServer" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="debug">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
... and WcfShareTest.exe.config:
Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<client>
<endpoint binding="netNamedPipeBinding"
contract="TestServer.ITestServer" name="DefaultBinding_ITestServer_ITestServer" address="net.pipe://localhost/TestServer" />
</client>
</system.serviceModel>
</configuration>
I have attached a zipped project to this post as well. I have cleaned the project before zipping it, still it contains a non-empty Debug output directory. The files in there are the two app.config files, along with the original output files generated by svcutil for reference. As for the Remoting implementation, I've also attached a screen shot of the server with two attached client instances.
As usual, I'll appreciate any comments on the design and implementation. Of particular interest IMO is the synchronization aspect here. I think the inter-thread syncronization looks uncritical: The server's hearbeat handler is invoked on a different thread, so I synchronized any method accessing the timeout counters (members m_nTimeout of both the server and client mirror image class), in particular the heartbeat handlers themselves, using the "quick and dirty" MethodImplAttribute approach. Or did I overlook something here?
Regarding the inter-process synchronization I'm still concerned about potential race conditions during server start-up and shutdown. While I have always started the client instances manually during my tests so far, allowing for a comfortable time span between two instance starts, the real-life app will often be started on schedule, making close-to-simultaneous client instance starts far more likely, so I think the server start-up should be of particular focus.
-
3 Attachment(s)
Re: Sharing objects between application instances using WCF
Almost one week later and no objections? Looks like my code isn't too bad... :) At any rate, here's another version to which I added extensive logging. I initially did that to be myself able to inspect what the code does closer to realtime, but I decided to also post it here for test and discussion.
Actually, there's only one change to the Server class that's not related to logging: Two new lines in the d'tor that stop the heartbeat timer and detatch the object's handler from the timer's Elapsed event. Obviously, not having them in the original code was a mistake which was unveiled during early tests with the logging version of the code: One time the heartbeat tick handler got called 170 ms after Server::Shutdown() returned, i.e. at a point in time when the server object already has been long time destroyed. And perhaps that would've even got through unrecognized if it hadn't given rise to an assertion failure in the logger module, thereby, as a side effect, reveiling a bug in there as well... :D
To be able to get timestamps that are half-way consistent between the distinct processes involved, the logger has a feature I called "hi-res synchronization" that gets set up in the TimestampSource c'tor, is activated by explicitly passing a set LogFlags::HiResSync to the logger instance getter when calling it for the first time, and IMO is somewhat hackish...
The log entries aren't written to the log file in a proper chronological sequence by the logger module. Properly sorting the log by timestamp, which of course is important in the scenario here, is done by the external tool logsortts that I have attached as well. It's a simple cosole tool and the respective ZIP only contains the single .cpp file.
The third attached file, SampleLog.zip, contains two logs taken from client/server sessions. Both sessions were quite similar to what the screen shot in the last post was taken from and lasted less than one minute. Yet they both contain 1k+ lines of log, from which clearly can be concluded that the log currently generated by the test scenario can pretty quickly mount up to some 100 kB. I'll certainly have much less logging later in the real-life app, and probably will reduce the amount of logging done in the test setup as well at some point.
While the log in the sample WcfShareTest.log was generated by manually starting the server and then two clients, SimulStart.log was created by quasi-simultaneously starting two client instances from a trivial batch file, without the server already running at that time. This was intended to stress-test the server start-up scenario. The test exposed exactly the desired behaviour: Eventually there was one server instance running with two clients attached. What pretty much puzzles me, though, is how that happened. :confused: According to the log both clients enter the "Starting server app..." part of the code within a time span of 17 ms from each other, start to wait for server start-up with a distance of 15 ms and eventually report a successful server start within 4 ms. Yet there's just one server instance running. I don't think there was a second server instance for a short time that then died silently. Not only that the log doesn't report anything like that, the server also has intentionally been written to produce noticable noise when there already is an instance of it running. This is a sub-scenario I was much concerned about and I'm glad it works, but I would also love to know why and how it works...
Note that the enclosed MiniLog module actually is a "light version" of a bigger logger module (about twice as much code lines) I commonly use in my apps. The test scenario code is prepared to optionally use the full-fledged logger module, but that's not included. Also, the two sample logs actually have been created by the big logger and I just removed some info I didn't intend to post publicly, but those produced by MiniLog are practically identical in layout.
-
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
While the log in the sample WcfShareTest.log was generated by manually starting the server and then two clients, SimulStart.log was created by quasi-simultaneously starting two client instances from a trivial batch file, without the server already running at that time. This was intended to stress-test the server start-up scenario. The test exposed exactly the desired behaviour: Eventually there was one server instance running with two clients attached. What pretty much puzzles me, though, is how that happened. :confused: According to the log both clients enter the "Starting server app..." part of the code within a time span of 17 ms from each other, start to wait for server start-up with a distance of 15 ms and eventually report a successful server start within 4 ms. Yet there's just one server instance running. I don't think there was a second server instance for a short time that then died silently.
I think you have some issues with regard to the use of the manualset event.
I see it's a manual reset named event, but I don't see where you set it or reset it. If you don't ever set it, then won't WaitOne(0) always false?
At any rate, you might consider using a named mutex to protect the server initialization code.
Code:
bool mutexWasCreated;
Mutex^ m = gcnew Mutex( false, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
// Block other processes
m->WaitOne( );
// Start up the server
if( mutexWasCreated )
{
// Startup up WCF server
}
// Allow access to other processes
m->ReleaseMutex( );
The code above should block additional processes from attempting to access the server while its initializing.
-
Re: Sharing objects between application instances using WCF
Thanks for your opinion. :)
Quote:
Originally Posted by
Arjay
I think you have some issues with regard to the use of the manualset event.
I'd say the prevalent issue here is that (and why) I didn't encounter any issue in the SimulStart run documented in the log. :ehh:
Quote:
I see it's a manual reset named event, but I don't see where you set it or reset it. If you don't ever set it, then won't WaitOne(0) always false?
It gets set and reset in these two static Server methods that are called from the server form class' c'tor and d'tor (lines highlighted in red):
Code:
// To be called upon start-up of the supposedly singular primary server .exe instance,
// returns true if no other instance is running yet, i.e. the "launched" event was not set:
bool Server::Startup(Action ^dltShutdownRequestCallback, Action<int> ^dltStatusReportCallback)
{
LOG_FUNCTION_ENTRY
EventWaitHandle ^evt = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
if (evt->WaitOne(0)) {
evt->Close();
Log::GetInstance()->WriteLine("Leaving " __FUNCSIG__ " (failure)");
return false; // Start-up failed: primary instance already running
}
s_evtServerLaunched = evt;
s_dltShutdownRequestCallback = dltShutdownRequestCallback;
s_dltStatusReportCallback = dltStatusReportCallback;
s_host = gcnew ServiceHost(Server::typeid, gcnew Uri("net.pipe://localhost/TestServer"));
s_host->Open();
evt->Set();
Log::GetInstance()->WriteLine("Leaving " __FUNCSIG__ " (success)");
return true;
}
// To be called upon shutdown of the singular server .exe instance:
void Server::Shutdown()
{
LOG_FUNCTION_ENTRY
if (s_evtServerLaunched) {
s_evtServerLaunched->Reset();
s_evtServerLaunched->Close();
}
if (s_host) s_host->Close();
LOG_FUNCTION_EXIT
}
Quote:
At any rate, you might consider using a named mutex to protect the server initialization code.
Code:
bool mutexWasCreated;
Mutex^ m = gcnew Mutex( false, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
// Block other processes
m->WaitOne( );
// Start up the server
if( mutexWasCreated )
{
// Startup up WCF server
}
// Allow access to other processes
m->ReleaseMutex( );
The code above should block additional processes from attempting to access the server while its initializing.
I'd say that's functionally equivalent or at least quite similar to what I actually used in the Remoting test scenario (and almost literally identical to what I currently use in the real-life app to protect the SMTP server/user name pair). However, I always found the way I test for a server instance already running during client start-up (in Server::GetInstance()) a bit awkward.
For the dual use it has here, i.e. both protecting the singular server instance and indicating/signaling that the server runs on the client side, I found the solution using an event instead of the mutex more straightforward and elegant. One particular advantage of the event here is that, unlike a mutex, it gets signaled when it is set, not when it is released. And that allowed me to use the following code in the client start-up:
Code:
EventWaitHandle ^evt = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
if (!evt->WaitOne(0)) { // This means the server isn't running yet, so start it
log->WriteLine("Starting server app...");
Process ^proc = Process::Start(Path::Combine(Application::StartupPath, "TestServer.exe"));
Trace::Assert(proc != nullptr, "WCF Share Test: Failed to launch TestServer");
log->WriteLine("Waiting for server start-up...");
Trace::Assert(evt->WaitOne(10000), "WCF Share Test: Wait for TestServer start-up timed out");
proc->Close();
log->WriteLine("Server app started");
}
evt->Close();
The main reason why handling it that way became necessary was that, unlike Remoting, WCF doesn't tolerate an attempt to connect to the server when that hasn't finished start-up yet, so I was in need of a way to wait for server start-up to finish.
One additional thing your post and the thoughts I had while writing this post made me consider is, though, whether it might be a good idea to protect the phase from the creation of the event object to the first highlighted line in the first code snippet above by an additional global mutex.
BTW, can't lines 3 to 6 of your code snippet be contracted to:
Code:
Mutex^ m = gcnew Mutex( true, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
-
1 Attachment(s)
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
BTW, can't lines 3 to 6 of your code snippet be contracted to:
Code:
Mutex^ m = gcnew Mutex( true, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
No. The explicit WaitOne() and ReleaseMutex() calls are needed to synchronize additional clients while the server is starting up.
Consider the following code where a 10 second sleep is used to simulate the server startup.
Code:
using namespace System;
using namespace System::Threading;
using namespace System::Diagnostics;
int main(array<System::String ^> ^args)
{
bool mutexWasCreated;
Console::WriteLine( System::String::Format( L"Starting client: {0}", DateTime::Now ) );
Mutex^ m = gcnew Mutex( false, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
// Block other processes until startup has completed
m->WaitOne( );
// Start up the server
if( mutexWasCreated )
{
Console::WriteLine( System::String::Format( L"Starting server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
// Simulate startup up of WCF server (pause 10 seconds)
Thread::Sleep( 10000 );
}
// Allow access to other processes after startup has finished
m->ReleaseMutex( );
Console::WriteLine( System::String::Format( L"Using server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
Console::WriteLine( System::String::Format( L"Client has access: {0}", DateTime::Now ) );
Console::ReadLine( );
return 0;
}
In the Visual Studio IDE, open multiple instances by clicking "Debug\Start without debugging" (or Ctrl+F5).
Notice the timings of "Client has access". You'll see that clients other than the first instance have to wait 10 seconds before getting access.
If you set the change the TakeOwnership to true during the mutex creation and remove the calls to WaitOne and ReleaseMutex, you'll see the "Client has access" appear immediately, which proves the clients aren't waiting for the server startup.
Output (with WaitOne and ReleaseMutex calls):
-
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Arjay
No. The explicit WaitOne() and ReleaseMutex() calls are needed to synchronize additional clients while the server is starting up.
OIC, I think I got the point now. Guess I was misled by this comment line in your code:
Quote:
Code:
// Block other processes until startup has completed
m->WaitOne( );
I'd say to block other processes requesting initial ownership during construction of the mutex is enough, yet not to block this process.
Thank you not only for the explanation, but in particular for that illustrative demo code that allowed me to instantly and easily check out some variations. :)
Also, the simple structure of your sample inspired me how to protect server start-up in my test code with a mutex. Now it looks like this:
Code:
// To be called upon start-up of the supposedly singular primary server .exe instance,
// returns true if no other instance is running yet, i.e. the "launched" event was not set:
bool Server::Startup(Action ^dltShutdownRequestCallback, Action<int> ^dltStatusReportCallback)
{
LOG_FUNCTION_ENTRY
Log ^log = Log::GetInstance();
bool bIMTheOne;
log->WriteLine("Acquiring server start-up mutex...");
Mutex ^mtxStartup = gcnew Mutex(true, "WcfShareTestServerStartupMutex", bIMTheOne);
if (!bIMTheOne) {
log->WriteLine("Mutex acquisition failed");
mtxStartup->Close();
log->WriteLine("Leaving " __FUNCSIG__ " (failure)");
return false; // Start-up failed: another instance is already starting up
}
log->WriteLine("Mutex acquired");
EventWaitHandle ^evt = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
if (evt->WaitOne(0)) {
evt->Close();
mtxStartup->ReleaseMutex();
mtxStartup->Close();
log->WriteLine("Leaving " __FUNCSIG__ " (failure)");
return false; // Start-up failed: primary instance already running
}
s_evtServerLaunched = evt;
s_dltShutdownRequestCallback = dltShutdownRequestCallback;
s_dltStatusReportCallback = dltStatusReportCallback;
s_host = gcnew ServiceHost(Server::typeid, gcnew Uri("net.pipe://localhost/TestServer"));
s_host->Open();
evt->Set();
mtxStartup->ReleaseMutex();
mtxStartup->Close();
log->WriteLine("Leaving " __FUNCSIG__ " (success)");
return true;
}
However, I'm using the initial ownership approach here, since I instantly fail start-up if the mutex can't be acquired: no need to wait. I think now it's really fool-proof, though, according to my observations from the SimulStart run (of which I still don't know how exactly that happened), perhaps the extra protection isn't even necessary. OTOH it doesn't really hurt to have it in the code either... :)
-
Re: Sharing objects between application instances using WCF
Your startup code is still incorrect.
Compare the timings of the following code snippets
Good
Code:
int main(array<System::String ^> ^args)
{
bool mutexWasCreated;
Console::WriteLine( System::String::Format( L"Starting client: {0}", DateTime::Now ) );
Mutex^ m = gcnew Mutex( false, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
// Block other processes until startup has completed
m->WaitOne( );
// Start up the server
if( mutexWasCreated )
{
Console::WriteLine( System::String::Format( L"Starting server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
// Simulate startup up of WCF server (pause 10 seconds)
Thread::Sleep( 10000 );
}
// Allow access to other processes after startup has finished
m->ReleaseMutex( );
Console::WriteLine( System::String::Format( L"Using server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
Console::WriteLine( System::String::Format( L"Client has access: {0}", DateTime::Now ) );
Console::ReadLine( );
return 0;
}
Bad
Code:
int main(array<System::String ^> ^args)
{
bool mutexWasCreated;
Console::WriteLine( System::String::Format( L"Starting client: {0}", DateTime::Now ) );
Mutex^ m = gcnew Mutex( true, "WcfShareTestServerLaunchedEvent", mutexWasCreated );
// Block other processes until startup has completed
// m->WaitOne( );
// Start up the server
if( mutexWasCreated )
{
Console::WriteLine( System::String::Format( L"Starting server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
// Simulate startup up of WCF server (pause 10 seconds)
Thread::Sleep( 10000 );
}
// Allow access to other processes after startup has finished
// m->ReleaseMutex( );
Console::WriteLine( System::String::Format( L"Using server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
Console::WriteLine( System::String::Format( L"Client has access: {0}", DateTime::Now ) );
Console::ReadLine( );
return 0;
}
Bottom line, is that setting TakeOwnership value to True, isn't sufficient to block the opening of the mutex.
-
1 Attachment(s)
Re: Sharing objects between application instances using WCF
Right, your Bad sample doesn't behave according to the specs, but my code rather behaves like this (or at least is supposed to):
Code:
int ServerSimulator()
{
bool mutexWasCreated;
Console::WriteLine( System::String::Format( L"Starting server app: {0}", DateTime::Now ) );
Mutex^ m = gcnew Mutex( true, "WcfShareTestServerStartupMutex", mutexWasCreated );
// The mutex is used to protect the server start-up phase only
if( !mutexWasCreated )
{
Console::WriteLine( L"Server start-up failed: another server instance is already starting up\n"
L"right now" );
m->Close();
return 1;
}
EventWaitHandle ^e = gcnew EventWaitHandle(false, EventResetMode::ManualReset, "WcfShareTestServerLaunchedEvent");
// The event is used to indicate a running (i.e. completely started-up) server instance to both clients and
// other server instances
// The event is the only server-owned synchronization object that is ever accessed by clients
if (e->WaitOne(0)) {
Console::WriteLine( L"Server start-up failed: there's already another server instance running that\n"
L"has finished start-up" );
e->Close();
m->ReleaseMutex();
m->Close();
return 1;
}
Console::WriteLine( System::String::Format( L"Starting server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
// Simulate startup up of WCF server (pause 10 seconds)
Thread::Sleep( 10000 );
// Set the event to indicate a valid running server instance
e->Set();
// Start-up is finished, so release the start-up mutex
m->ReleaseMutex( );
m->Close();
// The actual Server::Startup() ends here
Console::WriteLine( System::String::Format( L"Using server - pid: {0}", Process::GetCurrentProcess( )->Id ) );
Console::WriteLine( System::String::Format( L"Client has access: {0}", DateTime::Now ) );
// Simulate server up time (wait for key press)
Console::WriteLine( L"Hit <Enter> to shut down server..." );
Console::ReadLine();
// The following happens in Server::Shutdown()
// Reset the event indicating a running server instance
e->Reset();
e->Close();
// Actual WCF service shutdown goes here
Console::WriteLine( L"Server (pid: {0}) was shut down at: {1}", Process::GetCurrentProcess()->Id, DateTime::Now);
return 0;
}
int main(array<System::String ^> ^args)
{
int nRet = ServerSimulator();
Console::WriteLine ( L"Hit <Enter> to exit..." );
Console::ReadLine();
return nRet;
}
And here's a screen shot of it, analogous to yours from post #14:
-
Re: Sharing objects between application instances using WCF
Ok, in the meantime I have migrated the real-life app (as described in the OP of the Remoting thread) to the client/server architecture.
However, I considerably revamped the server design. The reason was that I didn't find anything resembling the functionality of the Server class from the Remoting scenario whose instances can simply be returned to the client and then be "remote controlled" because the class is derived from MarshalByRefObject. One alternative I considered was returning an integral handle to the client that identifies the related server-side object, but that somehow felt a bit too old-school... :rolleyes: The next idea was to use that handle, but wrap it with a client-side proxy object. Looked better, but again that would require implementing part of the server functionality on the client side, like I did in the RemotingShareTest solution.
What I'm currently at is a design that does use a per-client proxy object, but that is located at the server side and remote-instantiated from the client. These objects of type SmtpIdentityProxy refer to reference-counted instances of a class SmtpIdentity (n-to-1 relation) that get created per SMTP server/user name pair. These in turn have some sort of n-to-1 relation to the Server class that's still there, but merely is a private static-members-only class now. It just exposes four methods to the server GUI app, two of which are Startup() and Shutdown() known from earlier in this thread and the Remoting thread, and one of which is rather private to the server class, has only been exposed for diagnostic purposes and is currently unused from outside the server class anyway. I think this design much better fits the WCF architecture.
Works mostly fine so far. :D The reusable SMTP identity objects allow a back-to-back mail delivery distance of as little as observed 3 ms, as opposed to the logout/login distance of 300 ms in the former solution. And of course they reduce the stress imposed on the SMTP server by using fewer SMTP sessions which was the primary intention behind this approach.
However, there still are some multithreading issues remaining, or rather non-multithreading issues. MSDN docs originally made me think that setting SessionMode to Required in the service contract as well as setting InstanceContextMode to PerSession and ConcurrencyMode to Multiple in the ServiceBehaviorAttribute, along with taking care of synchronization in my classes allow instant parallel processing of requests issued by the clients. However, this is not the case: Everything goes on in the context of the server app's GUI thread (managed thread ID 1) except things like decrementing timeout counters and timeout-based destruction of SMTP identity objects (no surprise since this happens in the context of a System::Timers::Timer tick event handler) and (!) destruction of identity proxy instances initiated by calls to ClientBase<ISmtpIdentityProxy ^>::Close() on the client side.
Is there really no way to achieve parallel handling of requests regarding independent SMTP server connections except explicitly implementing the asynchronous pattern (see http://msdn.microsoft.com/en-us/libr...ncpattern.aspx), IOW may I have overlooked anything obvious? I'm not afraid of actually implementing that, still of course I'd prefer a simpler solution if one is available. For the case I actually need to implement concurrency on my own, I'm currently considering two fundamental approaches:
- Queue a thread pool execution request for each mail to be submitted and have them compete by synchronization or
- set up a queue of mails to be submitted myself for each SMTP server connection (IOW SMTP identity object) with a dedicated thread servicing it.
The first approach may seem simpler at first sight, but it may make it more difficult to make sure all requests on an SMTP identity instance have been serviced and the instance can be shut down cleanly. Any comments on which approach is to be preferred and why is welcome. :)
On the side note: This again made me experience that multithreading issues may lead to weird results and be tricky to diagnose. At some point it even made me suspect that VC++ 2010 might not correctly render short-circuit evaluation of boolean expressions in C++/CLI. Of course it actually does that perfectly, but it took me careful examination of some disassembly to prove that. Eventually it turned out that the observed behaviour was due to several timer tick event handler invocations on the thread pool got blocked requesting a lock on a long-locked object, thus piling up and then all got executed at once when the lock was eventually released... :rolleyes:
-
Re: Sharing objects between application instances using WCF
In the past days I have changed the server of the real-life app to implement the asynchronous protocol for the exposed mail sending method (SmtpIdentityProxy::Send()) and the method of SmtpIdentity of the same name and signature to which the calls are simply relayed by the proxy by calling it on an SmtpIdentity member it contains. (I would have been done with that quicker if I hadn't made a tiny but fundamental one-line mistake in the implementation of the asynchronous pattern that took me three or four days to find. I'll certainly never make that mistake again... ;))
As the way to fundamentally implement asynchronous functionality on the server side I chose option #4 out of the two options mentioned in my last post: using SmtpClient::SendAsync() instead of merely Send(). This is a rather natural option that I simply failed to consider for some time and which makes the whole thing surprisingly simple. :) (Option #3 would have been tasks.)
Another thing I really like about WCF is that it is able to handle interfacing between the synchronous and asynchronous protocols on the client and the server side transparently, so I didn't even need to modify the client to accomodate that design change. (I actually did a few small changes to the client, but not in this respect.)
Asynchronous sending apparently happens in a separate thread private to the SmtpClient object. When my server gets passed a mail while the SmtpClient instance it is meant for is busy anynchronously sending a previous mail (of which I need to keep track myself, since there's no way to query that state), the new mail is enqueued and later fed to the SmtpClient in its SendCompleted event handler.
While that strategy pretty much mitigates it by reducing the load on the server's GUI thread, it still doesn't solve the problem of practically any server activity taking place in that thread, as described in my last post. The server runs much smoother now, still the problem of clustered heartbeat handler invocations remains to some extent and causes timeout counters to be off occasionally. However, the worst result of that effect I observed on the new version of the server was a timout meant to be five seconds actually being three seconds, but already that is much better than before, is an exception as I usually observe the timeouts to be reasonably exact, and the code is written so that there's no risk of accidentally destroying an object due to timeout when it's actually still in use. Currently I'm thinking about a mechanism to detect and report congestions on the heartbeat ticks without the need to log each invocation of the tick handler which pretty much clutters the log file. (I had that kind of logging for some time but the single line responsible for that is currently commented out.)
Another thing, unrelated to the above: The behavior I observed in the SimulStart.log file of mysteriously starting just a single server instance when simultaneously starting two client instances is a curious exceptional behavior I still have no idea of why it happens. The common case actually is, as initially expected, that two server instances get started, only one of which will win. Ok, so I changed the server to die silently if it's the loser in such a launch collision. I implemented that by simply calling Close() in the main form's constructor in case of a collision (i.e. if Server::Startup() returned false). It took some time to realize that this actually causes a problem: An ObjectDisposedException gets thrown when, as I interpret the stack trace, something (not in my code) attempts to set the main form's visibility though the form's window handle has never been created. That was rather sublime because in the absence of an existing main form, the exception doesn't pop up on the screen, but instead silently gets posted to the Windows event log.
Any suggestion on how to resolve that the best way? I may postpone the call to Close() until the window handle actually has been created, probably in the form's Load event handler. OTOH I'd like to have the superfluous server instance terminate as early as possible. Is there a way to do that in the form's constructor without raising an exception and in a not so hackish way?
Finally, I'm currently uncertain about the responsibility for closing the synchronization object returned by IAsyncResult::AsyncWaitHandle. The code sample on http://msdn.microsoft.com/en-us/libr...yncresult.aspx seems to suggest that closing it is the responsibility of the code calling my asynchronous interface (here: the WCF infrastructure). But what if the caller doesn't make use of that object at all, which seems to be rather common from the code I've seen all around? An idea might be to not even create the object before it gets requested by a call to that property's get accessor. However, that may become complicated if I also use the object internally, which I do in my code.
-
Re: Sharing objects between application instances using WCF
Some debugging, showing information that, due to implementation details of the logger, couldn't be seen in the log file, reveiled that calling Form::Close() from within the form's c'tor really was a big-time silly idea. :blush: That leads to an implicit and of course synchronous call to the d'tor, and shortly after that, the c'tor returns as if nothing exciting would have happened. Not hard to imagine that this leads to desastrous consequences... :eek: I fixed that by moving the call to Server::Startup() and the call to Close() to the form's Load event handler, as outlined in my previous post. That increases the lifetime of a server that fails start-up from around 50 ms to around 100 ms, but, honestly, no big deal either, so what? :cool:
I also was able to remedy the problem of lacking multithreading. That problem was due to the fact that I instantiated the ServiceHost on the server's GUI thread, which (of course) is attributed [STAThread], which AFAIK is mandatory for the Windows Forms infrastructure to work. I fixed it by creating a dedicated thread with ApartmentState::MTA. That thread's worker function now contains the core parts of both the start-up and shut-down code (though, in particular regarding the start-up, that is not the majority of code lines), with a WaitOne() on a newly introduced shut-down event in between. As an appreciated side effect this also allowed me to improve encapsulation a bit by making some important objects local to the worker function that previously were static class members to allow access from both the start-up and shut-down code. :)
Now everything is beautifully multithreaded, and the modification wasn't even really that much effort, since the server code had already been designed with thread-safety in mind before anyway. :cool: Now having the server-side handling of mail sending requests implemented using the asynchronous protocol and SmtpClient::SendAsync() may be overkill, but, OTOH, now that I already have it that way, there's no relevant reason to change that back to the synchronous protocol either, is there?
Instantiating the ServiceHost on an MTA thread again was something I simply failed to consider for some time. That was due to the fact that MSDN claims it wouldn't make a difference anyway as long as I'm not using COM, in conjunction with my belief that I am not actually using COM. Now the facts seem to prove that either MSDN's claim of irrellevance is wrong or I actually am using COM which would mean that under the hood WCF uses a COM-based implementation (at least in conjunction with the netNamedPipeBinding).
Eventual it looks like I figured it all out. :D So unless someone comes along and posts something along the lines of "OMG, what are you doing!?", I'll probably mark the thread resolved in a week or so. :wave:
-
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
I'll probably mark the thread resolved in a week or so. :wave:
I wouldn't be so hasty. Give it some time. :)
-
Re: Sharing objects between application instances using WCF
Quote:
Originally Posted by
Eri523
I'll probably mark the thread resolved in a week or so.
No!!! Don't do this! Plzzzzzzzzzzzzzz!!!
-
Re: Sharing objects between application instances using WCF
:lol: Oooh... You guys are kidding, aren't you? ;) My "OMG, what are you doing!?" was (of course) meant along the lines of "Oh, what a crappy code you're writing/using there!?". Perhaps I should choose my words more carefully - especially around midnight... :rolleyes:
At any rate, your wish is my command. :) Here's some more to ruminate about...
As my last post indicated, I felt I was almost done with this, merely facing a few minor issues I could sort out quickly. One of those was that, on the client side, I just get thrown a naked ServiceModel::FaultException (as opposed to a FaultException<TDetail>) in response to an exception getting thrown on the server side while processing a request issued by the client. These exceptions always carry the same sterotypical message along the lines of "The server couldn't process the request due to an internal error. Please activate includeExceptionDetailInFaults in the servive behavior if you want to get more information". However, I'm quite sure I do have activated that, just like in the test project attached to post #11, where that works like a charm. In fact, the real-life app's server app.config mostly is a modified copy of the one from the test project.
I didn't mind that too much yet because the stereotypic message is enough to indicate that something went wrong on the server side at all, and the server catches exeptions resulting from the actual mail sending attempt, writes them to the log file and finally rethrows them, so I can look them up later. However, now that I was going to fix it, this seemingly harmless issue turned out to actually be big-time stubborn. :sick: I have examined the four app.config files (for the client and the server from both the real-life app and the test project) with an XML editor, Notepad++ and the Service Configuration Editor for hours but still wasn't able to spot what's wrong.
I have some gut feeling that I actually overlooked something really basic. Perhaps a fresh pair of eyes can see more than I can at the moment, maybe even pretty quickly. So here's the real-life app's server app.config file:
Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<!-- ... -->
</appSettings>
<system.net>
<mailSettings>
<!-- ... -->
</mailSettings>
</system.net>
<system.serviceModel>
<services>
<service name="esendmailsvr.ISmtpIdentityProxy" behaviorConfiguration="debug">
<endpoint address="net.pipe://localhost/esendmailsvr"
binding="netNamedPipeBinding"
contract="ISmtpIdentityProxy"
name="esendmailsvr.ISmtpIdentityProxy" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="debug">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
... and the one of the client:
Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<!-- ... -->
</appSettings>
<system.net>
<mailSettings>
<!-- ... -->
</mailSettings>
</system.net>
<system.serviceModel>
<client>
<endpoint binding="netNamedPipeBinding"
contract="ISmtpIdentityProxy" name="esendmailsvr.ISmtpIdentityProxy"
address="net.pipe://localhost/esendmailsvr" />
</client>
</system.serviceModel>
</configuration>
And, for reference, the config files from the test project where the marshalling of exceptions from the server to the client works perfectly. Compared to the versions of these files from the last version of the test project I attached, the server config has just one additional line in the appSettings section that is certainly unrelated to WCF, and anyway, it has worked with that line as well as without it. The client config is absolutely identical to the attached one.
For the server:
Code:
<configuration>
<appSettings>
<add key="logfile" value="WcfShareTest.log" />
<add key="dontFailSilentlyOnLaunchCollision" value="true" />
</appSettings>
<system.serviceModel>
<services>
<service name="TestServer.Server" behaviorConfiguration="debug">
<endpoint address="net.pipe://localhost/TestServer"
binding="netNamedPipeBinding"
contract="TestServer.ITestServer" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="debug">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
... and the client:
Code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="logfile" value="WcfShareTest.log" />
</appSettings>
<system.serviceModel>
<client>
<endpoint binding="netNamedPipeBinding"
contract="TestServer.ITestServer" name="DefaultBinding_ITestServer_ITestServer" address="net.pipe://localhost/TestServer" />
</client>
</system.serviceModel>
</configuration>
I'm pretty much out of ideas regarding this at the moment. Do you have some? I'm pretty sure the problem wasn't caused by the recent changes regarding multithreading I described in my last post or the change to the asynchronous protocol on the server side, since it already has been present long before. The only remarkable and perhaps relevant difference I can think of at the moment is that the test client is a Windows Forms app while the real-life client is a console app. However, I don't see how that may influence the behavior of the WCF infrastructure in the way observed.
Aside from that, I think the program could probably benefit by some fine-tuning of the WCF timeout and buffer size settings. It has worked fine with the defaults so far, but none of the test mails I sent was larger than 20 kB and it never were more than four (or perhaps six) of them at a time. However, before I do that, I need to thoroughly read up on these settings again and envision not only how they interact with each other, but also with the time outs I'm maintaining myself.
-
Re: Sharing objects between application instances using WCF
In the meantime, while looking for a way to determine at runtime which behavior configuration the service actually is using, I discovered that the ServiceBehaviorAttribute has an IncludeExceptionDetailInFaults property as well. Setting that to true on my service activated marshaling of exceptions to the client as originally intended, proving BTW that this problem was in no way related to the client and the fact that it's a console app.
However, on mid-term, I'll most probaly implement a fault contract anyway, since the ExceptionDetail class doesn't convey some specifics of the SMTP faults like the status code or the list of failed recipients, which of course are of interest to the client, and I learned that implementing that probably won't be that difficult either. Other exceptions than SmtpException or derived classes are of no interest to the client since they either indicate an internal failure of the server or a server failure that has been caused by the client improperly interacting with the server, which of course shouldn't happen in the first place.
I still would love to know why the server keeps ignoring the behavior configuration set up in the app.config file, though... :confused:
