How to make "offline-connections" work??

Apr 22, 2011 at 6:27 AM

Hi !

I am just working on the PubSub example again and modified it so, that is using MSMQ instead of TCP.
This works.

What do I have to do or change in my code, so that the following line would succeed, even if the remote
service is not running:

var w = space.ConnectWorker<PNewsAgency>(@"RemoteComputer\private$\PubSubServer/news");

Any help would be great.

In usual MSMQ programming this works. The remote machine and/or the MSMQ service can be offline.
The infrastructure ensures, that the message is delivered finally.

Another question for this scenario:How to set "Message.TimeToBeReceived" property directly from the
configuration or get an instance reference for the message.

Thanks so far!

br++mabra

Coordinator
Apr 26, 2011 at 8:43 AM
Edited Apr 26, 2011 at 8:43 AM

Hi mabra,

Unfortunately this is currently not possible, since the ConnectWorker call checks if the worker to which the connection should be established really exists, if the worker is allowed to be accessed (in case when security functions are active) and some other things. Only once the connection is established, it is possible to send messages while the worker is temporarily offline.

Concerning the TimeToBeReceived, there is currently also no possibility to set this value, but it seems this could be a helpful thing to add to the MSMQ transport service. In your scenario, do you want to use the same value all the time (for all messages that are sent by a certain appspace instance), or do you want to set different values for different messages (define the TimeToBeReceived value for every sent message separately)?

Best regards
Thomas

Apr 26, 2011 at 2:16 PM

Hi thomass !

Thanks for your reply.

It would be great, if "ConnectWorker" could work by configuration ...

About the TimeToBeReceived, sad to say:The answer is no [I need different expirations for diffent data].

I am even seeing much more neccesities for my connection scenarios, which even a bus might be just
currently not able to handle ...

I am having a lot of different sites, where - in minimum one - of my agents should run and publish data.
If these data finally reach one of the destination-queues, they must be handled by peeking the queue, not
reading them. If finally the destination database is ready to process, these messages should be read from
the queues and pushed into the DB. And for load-balancing, I will need even different queues.

I'll additionally have a deeper look into some of the busses or have to wire something by myself [the
not wanted option ;-) ].

But I'll probably use AppSpace for my other direct connections as a communication infra.

Thanks anyway!

br++mabra

 

Coordinator
Apr 27, 2011 at 8:53 AM

Hi mabra,

We might be implementing a variant of ConnectWorker in the future which doesn't need a direct connection, but I cannot say it for sure right now.

As for your communication scenario, you seem to have some special requirements involving message queues, so I agree with you that it is probably better to handle them outside of the appspace.

Best Regards
Thomas

Apr 27, 2011 at 1:53 PM

Hi !

I am thinking about msmq, because it can ensure that the messages finally reach
their destination. And I even need an answer later, going the same way and - naturally [!==],
the space/job/agent, which initially sent out a message, is not present, when the answer
comes in ;-)

I am mostly working with infrastructure and I think, the famous "Fallacies of Distributed Computing"
have been written by an optimist ;-)

I have to deep more into bus-ses also.

br++mabra

Apr 29, 2011 at 2:18 PM

Hello!

I had a look to the modified PuSub sample again, just to understand the thinggy better.

I started both, server and client and message are exchanged. Then I stopped the client.
From the output of the server, I can see, that it runs and generates output, bu no messages
arrive at the clients message queue. I wrote a peek-reader to see, if they are just not
shown to by the mq admin tool, or if they are really not there.

If I start the client again, both, the client and my peekreader get's the messages, the
server generates. Then I kill the client-process directly. Then the messages from the
server continue to go to the client and my peekreader shows them fine and even the
managment console.

Then I start the client again. All messages which hungs around in the queue are deleted
and so, they are lost for the client. The client then just shows the new messages.

Could you tell me, in which class this behavior is defined? Additionally, are there
properties, which define this behavior?

Thans a lot!

br++mabra

Coordinator
Apr 30, 2011 at 2:27 PM

Hi mabra,

I fear there are some problems that will prevent your scenario from working as you expect it:

First, you say that you are killing the client. I assume that the server is hosting a worker and is communicating to the client via a response port. Within the appspace, a response port is identified by a guid, which is created when it is first used. Meaning, when the appspace instance is killed and then restarted, the response port will get a new guid, meaning that old messages cannot be matched to this new response port. Currently there is no way to assign a self-defined guid to a response port, so this behavior cannot be changed - a new instance of a port always means that a new guid is created. So, for offline messages, using response ports is unfortunately not possible right now.

The only thing has a persistant identifier is a worker. A worker is identified by its address, name and contract - so, if you restart a worker and these three things are completely the same, this worker will also be able to receive "old" messages. Unforunately, with the current appspace version, there is still a problem: As soon as the appspace starts up, it will immediately read all messages from the queue and try to hand it over to existing workers or response ports. But since you can only run workers when the appspace is already started, some messages may already have been read (and discarded) until the worker is running. A small time delay to allow starting workers before messages are received would probably solve this problem - I'll try it out and tell you when an update is available.

Best regards
Thomas

Coordinator
May 5, 2011 at 3:22 PM

Hi mabra,

I just tried out a small online/offline example, where the server goes offline and the client keeps on sending some messages. As soon as the server restarts, if the worker is also run directly after space startup, it will receive the messages that have been posted while it was offline. So, the scenario with workers going offline and then receiving messages that were send in the meantime when coming online again, should be no problem. Here is the code I used:

int receivedMessages = 0;
string msmqName1 = @".\private$\TestAppSpace";
string msmqName2 = @".\private$\TestAppSpace2";

//start server space and worker
XcoAppSpace server = new XcoAppSpace(@"msmq.queuename=" + msmqName1 + ";msmq.disposequeue=false");
server.Run<int>("myport", msg => Interlocked.Increment(ref receivedMessages));

XcoAppSpace client = new XcoAppSpace(@"msmq.queuename=" + msmqName2);

//connect to worker
var remotePort = client.Connect<int>(msmqName1 + "/myport");
//post some messages to see if the connection is working
remotePort.Post(1);
remotePort.Post(2);
Thread.Sleep(200);
Assert.AreEqual(2, receivedMessages);

//server goes offline
server.Dispose();

//post some messages while server is offline
remotePort.Post(3);
remotePort.Post(4);

//client goes offline
Thread.Sleep(100);
client.Dispose();


//restart server - should receive messages that have been sent while the server was offline
server = new XcoAppSpace(@"msmq.queuename=" + msmqName1);
server.Run<int>("myport", msg => Interlocked.Increment(ref receivedMessages));

Thread.Sleep(200);
Assert.AreEqual(4, receivedMessages);

server.Dispose();
May 20, 2011 at 1:49 PM

Hi Thomass!

Thanks, thanks for your work!!! And don't bother with me:I am in a "ultra-stress" situation in the moment and cannot take immidiate the time to follow this track.

But it looks good to me and I'll definitively give it a try!

br++mabra