Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 25780 invoked from network); 9 Feb 2007 06:49:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2007 06:49:21 -0000 Received: (qmail 72944 invoked by uid 500); 9 Feb 2007 06:49:26 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 72891 invoked by uid 500); 9 Feb 2007 06:49:26 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 72880 invoked by uid 99); 9 Feb 2007 06:49:26 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2007 22:49:26 -0800 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of sameera.madushan@gmail.com designates 64.233.182.190 as permitted sender) Received: from [64.233.182.190] (HELO nf-out-0910.google.com) (64.233.182.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2007 22:49:16 -0800 Received: by nf-out-0910.google.com with SMTP id o63so971401nfa for ; Thu, 08 Feb 2007 22:48:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PDdj53NK1q0vzs89r6DHsUkwni781iP224W+bkP3tQKyNBgSUquhiwuDH2vOff1x9kPpE7kJ4JKPt2SXQUifVrWyraYBcqaLTKkeRw3ynXeeKXqJ05QnQmemriULfth5HQn2xsiFFRA8bC9ZJIWHta5/CKxkHfVd9X3CnocThHk= Received: by 10.49.107.8 with SMTP id j8mr877269nfm.1171003735372; Thu, 08 Feb 2007 22:48:55 -0800 (PST) Received: by 10.48.254.18 with HTTP; Thu, 8 Feb 2007 22:48:55 -0800 (PST) Message-ID: <4f5c8bd80702082248w7fdde606w9d6ff6b581255686@mail.gmail.com> Date: Fri, 9 Feb 2007 12:18:55 +0530 From: "Sameera Madushan" To: axis-dev@ws.apache.org Subject: Re: [axis2] Pinging capability to services deployed in Axs2 In-Reply-To: <45CC13A7.7020608@opensource.lk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25878_12339297.1171003735246" References: <4f5c8bd80702061028r63b03ba6r9c4dddb2c2890fb1@mail.gmail.com> <45C9551C.5030408@opensource.lk> <4f5c8bd80702062129q299a3bd5j8f06e3c915f50cc8@mail.gmail.com> <45CA9A6C.4080400@sosnoski.com> <1170979109.21422.11.camel@localhost.localdomain> <45CC13A7.7020608@opensource.lk> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_25878_12339297.1171003735246 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi deepal, > > >The problem is that pinging at the handler level basically amounts to > >just asking "is there such a service?". Having it go to the message > >receiver allows the ping to be responded to based on more useful data- > >such as did the impl class or script or whatever load etc.. So its > >really a question of fidelity- yes some level of liveness checking can > >be done at a handler level but you get much improved info by getting the > >ping to the message receiver. > > > > > Service might have more than one MRs (most of the time it does) so > checking only one MR wont give you the accurate results. The other > problem I have is which MR you are going to call when you receive a ping > request , are you going call all the MRs or only one. There can be two types of ping requests. 1. Service level ping requests. 2. Operation level ping requests. In the first case, you are correct, we need to ping all the operations within the service. Then in the ping response simply we can say whether the service is up or not, or we can include all operations and their status. In the second case we can directly ping the MR assinged to the requested operation and the response accordingly. This implies that we need to develop a schema for the ping requests and ping responses. thanks Sameera. ------=_Part_25878_12339297.1171003735246 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi deepal,

>The problem is that pinging at the handler level basically amounts to
>just asking "is there such a service?". Having it go to the message
>receiver allows the ping to be responded to based on more useful data-
>such as did the impl class or script or whatever load etc.. So its
>really a question of fidelity- yes some level of liveness checking can
>be done at a handler level but you get much improved info by getting the
>ping to the message receiver.
>
>
Service might have more than one MRs (most of the time it does) so
checking only one MR wont give you the accurate results.  The other
problem I have is which MR you are going to call when you receive a ping
request , are you going call all the MRs or only one.

There can be two types of ping requests.

1. Service level ping requests.
2. Operation level ping requests.

In the first case, you are correct, we need to ping all the operations within the service. Then in the ping response simply we can say whether the service is up or not, or we can include all operations and their status.

In the second case we can directly ping the MR assinged to the requested operation and the response accordingly.

This implies that we need to develop a schema for the ping requests and ping responses.

thanks
Sameera.


------=_Part_25878_12339297.1171003735246--