Return-Path: Delivered-To: apmail-ws-sandesha-dev-archive@www.apache.org Received: (qmail 7078 invoked from network); 11 Nov 2005 04:31:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Nov 2005 04:31:39 -0000 Received: (qmail 63911 invoked by uid 500); 11 Nov 2005 04:31:38 -0000 Delivered-To: apmail-ws-sandesha-dev-archive@ws.apache.org Received: (qmail 63874 invoked by uid 500); 11 Nov 2005 04:31:37 -0000 Mailing-List: contact sandesha-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list sandesha-dev@ws.apache.org Received: (qmail 63863 invoked by uid 99); 11 Nov 2005 04:31:37 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2005 20:31:37 -0800 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.68.3.41] (HELO wbm1.pair.net) (209.68.3.41) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2005 20:31:30 -0800 Received: by wbm1.pair.net (Postfix, from userid 65534) id E46C426C9E; Thu, 10 Nov 2005 23:31:14 -0500 (EST) Received: from 149.159.132.72 ([149.159.132.72]) (SquirrelMail authenticated user jaliya@opensource.lk) by webmail1.pair.com with HTTP; Thu, 10 Nov 2005 23:31:14 -0500 (EST) Message-ID: <1371.149.159.132.72.1131683474.squirrel@webmail1.pair.com> Date: Thu, 10 Nov 2005 23:31:14 -0500 (EST) Subject: Re: [Sandesha2] The Policy model From: jaliya@opensource.lk To: "Chamikara Jayalath" , "sandesha-dev@ws.apache.org" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Chamikara, When we design Axis2 the model that we discussed to handle policies was as follows. Axis2 handle the policies and each module can access the policy elements, which will be there in some context (service context) Please clarify why do we need to pass them around, if we can access them from anywhere. Thanks, Jaliya ----- Original Message ----- From: Chamikara Jayalath To: sandesha-dev@ws.apache.org Sent: Thursday, November 10, 2005 8:30 PM Subject: [Sandesha2] The Policy model Hi All, I'm working on implementing the policy model for sandesha2. Sanka has already created a RMPolicyBean and a PolicyUtil class which can be used to extract a RMPolicyBean out of a large Policy OM Element. The problem is how to pass this extracted information around the Sandesha2 framework. This is what I have in mind. Each messageContext should have an associated RMPolicyBean which contains its policy information. In the client side this information will be set by the user (probably wrapped by the stub). In the server side, a fixed set of policy values (given in the module.xml) will be loaded to the RMPolicyBean. This infoamtion will be later set to each messageContext. Here are how these policies can be used. Rretransmission interval, exponention backoff ----------------------------------------------------------------- The RetransmitterBean will adjust the nextTimeToSend after each retransmission. To calculate the nextTimeToSend, the sender will use these two policy values (with the sentCount property which gives the no. of times the message has been retransmitted) which can be obtained from the associated RMPolicyBean of the current message Context. Acknowledgement interval ------------------------------------- When adding a ack message the timeToSend will alsays be set to currentTime+Acknowledgement Interval so that the ack message will not be send before the interval get expired. When the sender detect an applicationMessage it will look for an ack of the same sequence. If it find one, the ack will be piggybacked. otherwise the ack will be sent as a standalone message. Inactivity timeout ------------------------ Each sequence has an associated lastRespondedTime property which gives the last time the other end responsed. Sender thread in it's each loop will look at the the lastRespondedTime of each sequence, if it find tha currentTime>lastRespondedTime+inactivityTimeout it will end that sequence. Comments ??? Thanx, Chamikara --------------------------------------------------------------------- To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org For additional commands, e-mail: sandesha-dev-help@ws.apache.org