From dev-return-1685-apmail-etch-dev-archive=etch.apache.org@etch.apache.org Mon Feb 11 23:52:01 2013
Return-Path:
X-Original-To: apmail-etch-dev-archive@www.apache.org
Delivered-To: apmail-etch-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 8432BE0AB
for ; Mon, 11 Feb 2013 23:52:01 +0000 (UTC)
Received: (qmail 48555 invoked by uid 500); 11 Feb 2013 23:52:01 -0000
Delivered-To: apmail-etch-dev-archive@etch.apache.org
Received: (qmail 48476 invoked by uid 500); 11 Feb 2013 23:52:00 -0000
Mailing-List: contact dev-help@etch.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@etch.apache.org
Delivered-To: mailing list dev@etch.apache.org
Delivered-To: moderator for dev@etch.apache.org
Received: (qmail 30897 invoked by uid 99); 11 Feb 2013 23:00:26 -0000
X-ASF-Spam-Status: No, hits=0.3 required=5.0
tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of fitzner.michael@gmail.com designates 209.85.215.50 as permitted sender)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:mime-version:in-reply-to:references:from:date:message-id
:subject:to:content-type:content-transfer-encoding;
bh=A5zXIAquvlzvTvrG/tE8YXZZaUQbEIb211YaJOwZhP8=;
b=vaLgqy1mCAKHuk3MEynvI1wPCang6ljIja6cbw+RFYYHFOE3RZjONIngQRLH4i1kh3
EojM53lZ69AsTG3UtP+NoY8B9YxjI6AjuKEJrwexhogRJsUuvRn7TPOR7BuKwVRItDex
RsnkbQCkk3JhroXlFMh9kUxofBsOpW0dFPKMz4IEN+Xq4vt87m6qkMPNJj3ypYZfwPMr
YtGA7NIg6YZrdE+STMtKs3eXHD+ks6IakhxQEHmbD+B9BiqF2GNFOwWmrmBDdswE1C8G
p2237vVQupu9r9InvnRCMtBZodVDS03zCYuRS6fIrvWV5Gq5OP2+MerVAUgLibN3Yc5n
wp+A==
X-Received: by 10.112.39.10 with SMTP id l10mr6449350lbk.79.1360623598903;
Mon, 11 Feb 2013 14:59:58 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <86D15D3953FD7546846601929374BD36042A565912@SMUCM02V.europe.bmw.corp>
References: <86D15D3953FD7546846601929374BD3604290C87BB@SMUCM02V.europe.bmw.corp>
<50C211F4.3070808@mac.com> <86D15D3953FD7546846601929374BD36042A565912@SMUCM02V.europe.bmw.corp>
From: Michael Fitzner
Date: Mon, 11 Feb 2013 23:59:28 +0100
Message-ID:
Subject: Re: Connection Timeout
To: dev@etch.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org
The c-binding supports the @Timeout construct, but doesn=91t handle
blocking send calls (hangs while sending the request data to the
remote station) with it. If the request was sent out completely and
you haven=91t received any answer in the defined time period a timeout
should occur.
The @Timeout relates to the answer of a call. So it is important to
differ between these two use cases:
1. Synchronous calls have a timeout to wait for the answers
2. Oneway calls have no answers, so you don=91t need to wait for it
In both scenarios it could happen that the TCP connection blocks
because the buffer runs out of space. If you have configured a send
timeout like =84etch.tcpconnection.timeout.send=93 it would be a good
approach to close the TCP connection internally and return an error
code to the caller.
Java code snipped:
try
{
OutputStream os =3D checkOutputStream();
os.write( buf, off, len );
if (options.autoFlush)
os.flush();
}
catch ( IOException e )
{
close( true );
throw e;
}
catch ( RuntimeException e )
{
close( true );
throw e;
}
I would prefer a generic solution and doesn=91t handle possible send
errors by each call.
Regards
Michael
2013/2/11 :
> Hi,
>
> unfortunately we are still using c-binding, which doesn't seem to support=
"@Timeout". Attached you can find an attempt to address the issue (thanks =
to Martin Veith for some valuable advise).
>
> Having the property "etch.tcpconnection.timeout.send" set, send-calls ret=
urn after the specified time interval and the result can be evaluated like =
in this example:
>
> if (is_etch_exception(result))
> {
> UInt32 errorcode =3D etch_exception_get_errorcode((etch_exception=
*)result);
> if (errorcode =3D=3D ETCH_EIO)
> {
> remote_base->stop_waitdown(remote_base, 1000);
> }
> }
>
> What do you think?
>
> Thanks
> Harald
>
> -----Urspr=FCngliche Nachricht-----
> Von: scott comer [mailto:wert1y@mac.com]
> Gesendet: Freitag, 7. Dezember 2012 16:58
> An: etch-dev@incubator.apache.org
> Betreff: Re: Connection Timeout
>
> which binding(s) are you using?
>
> java and c# implement these:
>
> there's a way to allow the caller to only wait a certain amount of time
> for a response, which is @Timeout(n) marks on a method (or interface).
>
> this causes the caller to abandon the call but doesn't kill the connectio=
n.
>
> adding term filter=3DKeepAlive to a connection url will cause a hung
> connection to be detected and killed. it must be added to the urls of
> both client and server.
>
> for a connection to hang means that one of the message readers has hung
> or is just super busy. one way this can happen is for a message reader
> to make an etch call. you must take steps to prevent this from
> happening. one way is to mark the method as being as asynchronous (which
> causes it to be executed on a thread pool instead of by the reader).
>
> scott out
>
> On 12/7/2012 6:31 AM, Harald.SC.Schmid@bmw.de wrote:
>> Hi,
>>
>> currently we have the problem that the client sometimes doesn't read dat=
a of an etch call for a long time. This blocks the calling server (in apr_s=
ocket_send()), in our case it leads to a reset as the server fails to call =
the watchdog for that time.
>>
>> My question is: can I initialize an etch connection with a timeout for a=
ll etch calls?
>> Further, when the timeout gets reached, I want to be able to terminate t=
he etch connection.
>> Is this already possible? If so, how does it work?
>>
>> Thanks,
>> Harald
>>
>>
>