PortSet<string,string> with Choice?
Hi,
This is my first post on CCR, I'm business software developer, but I like the service and message pattern of the library.
My question is about a Choice with same type ports. It seems that the Choice Arbiter doesn't scan the second port. For example:
class
Program{
static
void
Main(string
[] args){
Dispatcher dispatcher =new
Dispatcher();DispatcherQueue dq =new
DispatcherQueue();Port<string
> portA =new
Port<string
>();Port<string
> portB =new
Port<string
>();PortSet<string
,string
> portSet =new
PortSet<string
,string
>(portA, portB);//portA.Post("Port A"); //HonoredportB.Post(
"Port B"
);//Ignored
Choice choice =Arbiter.Choice<string,string>(portSet,
delegate(string message)
{
Console.WriteLine("First branch " + message);
},
delegate(string message)
{
Console.WriteLine("Second branch " + message);
});
Arbiter.Activate(dq, choice);
Console.ReadLine();
}
}
portA.Post("Port A") is honored, but portB.Post("Port B") is ignored. I'm using Visual Studio 2008 Beta.
Thanks
(my apologies if my english isn`t correct)
[3694 byte] By [
SERware] at [2008-3-1]
Hi this limitation is by design. A PortSet must have all types differ from each other. If they dont differ then the CLR runtime and the CCR cant distinguish between the underlying Port independent queues (and ther eis usually one for each type).
If you want to have a choice over two strings, you could define a simple wrapper, then use that as the second outcome (or for example if you the second outcome is an exception use PortSet
Code Snippet
class StringResult
{
public string Value;
};
PortSet<string,StringResult> resultPort = new PortSet<string,StringResult>();
Choice choice = Arniter.Choice<string,StringResult>(resultPort,
delegate (string s) {....},
delegate (StringResult sr) {....}
);
Thanks George,
All PortSet examples in the documentation have diferent types, but this limitation is not explicity stated (at least I was not aware).
I tried to use PortSet<string,string> with Choice to make it short, but there are many workarounds, the wrapper is one.
Thank again
SER
It seems to me that there are two issues here. First, the undocumented limitation on PortSets is good to be aware of. ... But I have to ask- why would you even try to put a Choice on a <string,string> portset? Semantically, it makes no sense for Choice to wait on identical types- it's like writing an 'if' statement like this:
if (typeof(result)==string) {
} else if (typeof(result)==string) {
}
Am I missing something?
Hi Rob,
Yes Rob, by the way the CCR is designed it is tautology.
I figured out the Choice Arbiter makes decisions based on port identity (executes first branch if it reads from first port in the PortSet...).
I was missing the decision is based on message type.
Thanks
Hi Rob,
Perhaps I didn't answer your main question in my previous post: why would you even try to put a Choice on a <string,string> PortSet?
Well, now I'm programming examples just for CCR discovering and learning.
My example is complicated to explain, but imagine you have two CCR async components developed by third parties. Each component has a string port internally constructed, and you need to coordinate in sequence their async posts: do some work when strings are received from the first component, and do other work when strings are received from the other (for example: log the strings prefixed by the name of the source component).
In principle you have string and string to coordinate (there are turnarounds, of course).
As George advises me in other thread, a Interleaved arbiter is best suited. But I tried first with a Choice Arbiter and it works (it works recreating the choice object after every task... not very pretty).
Thanks
