Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of wert1y@mac.com designates
 17.148.16.100 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Message-id: <4B4C8F31.8080900@mac.com>
Date: Tue, 12 Jan 2010 09:03:13 -0600
From: scott comer <wert1y@mac.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
To: etch-dev@incubator.apache.org, etch-user@incubator.apache.org
Subject: Re: Questions about the Event Dispatch and asynchronous callback
References: <77bb36841001120100y5511739cs2c32cf8775e597f@mail.gmail.com>
In-reply-to: <77bb36841001120100y5511739cs2c32cf8775e597f@mail.gmail.com>

Ranganath s wrote:
> Firstly
> i  would like to know how  Asynchronous Message works from server to client.
> Does that message get the response from the received end? if so what would
> be the duration of it?
>   
two way messages (we call them actions) to the client work exactly like 
two way messages to the server. the message sender formats the message 
and puts it on the wire and waits for a response. the message receiver 
reads the message from the wire, dispatches it to the appropriate 
implementation method, then formats the result (which may be a value 
including null, void, or an exception), and puts that on the wire back 
to the sender.

one way messages (we call them events) are slightly different. just as 
for two way messages, the sender formats the message and puts it on the 
wire. but then the sender returns immediately. as above, the receiver 
reads the message from the wire and dispatches it. if the implementation 
method returns normally (non-exception case), then nothing else is done. 
if the implementation method fails, then a special message with the 
exception is formatted and returned to the sender. normally this would 
fall into the "unwanted" message handler, delivered to the sender via 
_sessionNotify method. more or less an "FYI" thing.

the only thing changed by the asynchronous receiver tag in the above two 
scenarios is this: when the message is read from the wire, that thread 
(the message receiver thread) normally also dispatches the message to 
the implementation method. obviously while the implementation method is 
running no more messages can be read and dispatched. under asynchronous 
delivery, the message receiver thread hands the message to a thread pool 
to perform the task of calling the implementation method. the message 
receiver thread is then free to read and dispatch more messages. which 
means two things: asynchronous receiver messages can be executed out of 
order relative to other messages, each other, and in fact might be 
executed simultaneously to other messages; second, responses of 
asynchronous receiver messages might be delivered out of order relative 
to their execution sequence, with other messages and themselves. 
basically, when you have an asynchronous receiver declaration in the 
idl, you have to take much more responsibility for synchronization 
issues with respect to those methods and the rest.

not sure what "if so what would be the duration of it?" means.
> secondly , say i have a scenario where in i have 1 server say s1 with
> 4 clients say c1,c2,c3,c4 now when ever i change some data in c2 that needs
> to reflect in other clients as well.. So how could this be handled in Apache
> ETCH.
etch itself doesn't handle such a thing automatically. it is a message 
passing system, not a data sharing system. but you can use etch to 
handle data change scenarios like this:

if one of the clients changes some data, it uses a one way method to 
notify the server of the change. let's call that method 
dataChanged(...). let's assume the data is identified by name, the value 
can be any data type. let's declare dataChanged like this:

@Oneway
@Direction(Both)
void dataChanged(string name, object value)

the server, when it receives a dataChanged, updates it's copy and also 
turns around and calls each of the client's with the same information 
(the dataChanged method is bi-directional, so either client or server 
can call it). the clients, when they receive a dataChanged call, write 
down the new value, and life is good.

sort of. if c1 is telling the server that the value changed, obviously 
the server need not tell c1 the value changed. that's pretty easy.

the server needs to maintain a list of interested clients. in 
particular, when a client connection goes down, it should be removed 
from the list.

failure to send to a client should also not stop notification of other 
clients.

if both c1 and c2 change the same value, their messages will cross each 
other in transit and it is not defined what final value everyone ends up 
with. you would need to add a locking protocol and some sort of conflict 
resolution mechanism.

scott out