[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: Cleaning out some local patches of mine..
From:       Jeff Johnson <n3npq () mac ! com>
Date:       2008-12-05 8:38:54
Message-ID: 4920C6F3-4054-4F4C-880D-58108BC8EFC0 () mac ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Dec 5, 2008, at 2:47 AM, Per yvind Karlsen wrote:

> 2008/12/5 Per yvind Karlsen <pkarlsen@rpm5.org>
> Oh, and I also got this one:
> http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log
>  
> Any suggestions on what would be the best approach?
> Just use #ifdef vendor? It seems to me that this might be useful  
> also for
> others that are performing the same task with the possibility of  
> very high load..
> I forgot, FYI:
> # important patch fixing parse_hdlist (and so genhdlist2) on heavy  
> loaded boxes
> # (without this patch it timeouts after a read miss of 1 second  
> (even a pipe),
> # and there is no way we can retry since we would need to backtrack  
> the fd)
> 

Depends on what problem needs to be solved.

There needs to be a watchdog on network connecting waiting
for a response that isn't going to occur needs to be terminated.

But one timeout value for all usage cases can never be chosen  
successfully.
And there hasn't been a whole lot of thought into choosing the values.
Is 60 seconds enough?

FYI, its not impossibly hard to retrieve sufficient state from a FD_t  
to attempt a retry.
Not that retries solve any issue in general -- only in computer  
science is
retrying exactly the same operation expected to correct an error; most  
errors
are systemic, not transient, and so a retry just delays the inevitable  
failure.

73 de Jeff


[Attachment #5 (text/html)]

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><br><div><div>On Dec 5, 2008, at 2:47 AM, \
Per yvind Karlsen wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite">2008/12/5 Per yvind Karlsen <span dir="ltr">&lt;<a \
href="mailto:pkarlsen@rpm5.org">pkarlsen@rpm5.org</a>></span><br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Oh, and I also \
got this one:<br> &nbsp;<a \
href="http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&amp;view=log" \
target="_blank">http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&amp;view=log</a><br> \
<br>Any suggestions on what would be the best approach?<br>Just use #ifdef vendor? It \
seems to me that this might be useful also for<br>others that are performing the same \
task with the possibility of very high load..</blockquote> <div>I forgot, FYI:<br># \
important patch fixing parse_hdlist (and so genhdlist2) on heavy loaded boxes<br># \
(without this patch it timeouts after a read miss of 1 second (even a pipe),<br># and \
there is no way we can retry since we would need to backtrack the fd)<br> \
</div><br></div></blockquote><div><br></div>Depends on what problem needs to be \
solved.</div><div><br></div><div>There needs to be a watchdog on network connecting \
waiting</div><div>for a response that isn't going to occur needs to be \
terminated.</div><div><br></div><div>But one timeout value for all usage cases can \
never be chosen successfully.</div><div>And there hasn't been a whole lot of thought \
into choosing the values.</div><div>Is 60 seconds \
enough?</div><div><br></div><div>FYI, its not impossibly hard to retrieve sufficient \
state from a FD_t to attempt a retry.</div><div>Not that retries solve any issue in \
general -- only in computer science is</div><div>retrying exactly the same operation \
expected to correct an error; most errors</div><div>are systemic, not transient, and \
so a retry just delays the inevitable failure.</div><div><br></div><div>73 de \
Jeff</div><div><br></div></body></html>


["smime.p7s" (smime.p7s)]

0	*H
 010	+0	*H
 00 rk 0
	*H
0|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VI0 081202135405Z
091203135405Z0B10	UUS10UJeff Johnson10	*H
	
n3npq@mac.com0"0
	*H
0
Ҭ14B~:*;˄rx%I"^~22Wń9i,#O))~SC	` \
˨ŕ1i!~I5S)R&Ϥ(tuIAЈTOb߁>fN*5Q<1Rn&,f`iR!S~WUzsB \
SNg>Ox>ɐ{FMк00+00Q+0Eh \
ttp://www.trustcenter.de/certservices/cacerts/tc_class1_L1_CA_VI.crt02+0&http \
://ocsp.VI.tcclass1.trustcenter.de0U#0NjkJɻdK&0U00JU \
C0A0?	*,0200+$http://www.trustcenter.de/guidelines0U0UDL荺e9=7N&d?0TUM0K0I \
G EChttp://crl.VI.tcclass1.trustcenter.de/crl/v2/tc_class1_L1_CA_VI.crl03U%,0*+++
 +70U0
n3npq@mac.com0
	*H
c3#5@+Nwc<~3mJ \
2݉}dsOM3/cCåt(:ӌmxH#F?&N^?6c"*-7lu`+x|W \
ʕnbgҮV4H008 bnrd0 	*H
010	UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 UTC TrustCenter Class 1 \
CA1)0'	*H 	certificate@trustcenter.de0
080718113854Z
101231225959Z0|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VI00 	*H
0?N~ݤ㰾(ݙuLαlK%8H
~uH@MNCm]9Xq
K1~_݄Vfk(ѢzaW00'
@00+00L+0@http://www.trustcenter.de/certservices/ \
cacerts/tc_class_1_ca.crt0/+0#http://ocsp.tcclass1.trustcenter.de0U00JU \
C0A0?	*,0200+$http://www.trustcenter.de/guidelines0U0UNjkJɻdK&0U00 \
 ؆;http://crl.tcclass1.trustcenter.de/crl/v2/tc_class_1_ca.crlldap://www.trustc \
enter.de/CN=TC%20TrustCenter%20Class%201%20CA,O=TC%20TrustCenter%20AG,ou=rootcerts,dc=trustcenter,dc=de?certificateRevocationList?base?0
 	*H
ng,<H[<KB*8ُ˰y}e-pT-):mnzq/eJ̄tZմw"D˴W\&8kT.WƎ|W[30(0 \
0 	*H
0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
070806160927Z
090805160927Z0810UCAcert WoT User10	*H
	
n3npq@mac.com0"0
	*H
0
MǼ~arqC?j(Ѝ.=
ܐ[m47囵{Hǰmgk׼=FlFَ^ \
c9hٕ/,fOcY;ik"XFS	)֟W:Z#AqW:_rIqc&ZZAKBH
 oY_x(V!zd	AHDJAdG*QXVr:tpM00U00V	`HB
 IGTo get your own certificate for FREE head over to \
http://www.CAcert.org0@U%907++ +7

+7
	`HB02+&0$0"+0http://ocsp.cacert.org0U0
n3npq@mac.com0
	*H
BmC2G$+`?kdC
o߫'iƬ'9\q459xOS@B= \
49ێ0أZ-n!Hrλy)gPmcFkrzGr1d3)g"LZ\bkR&h@[%|%@ht'?Нc]y4J


m
!ϵ[4QB}bK_gD,	?
wG:U\XC\!}i)7%7ufmW]-x|̭QćHxNF%3z3rR>~c͛y2GL<n#K/
  (_Q7nfrCejT \
q$,76ICm@C@)H4{\ZX̢T@niQjcN'.i. +(a
=F(>O1B0>00|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VIrk 0	+ 0	*H 	1	*H
0	*H
	1
081205083855Z0#	*H
	1'::@,ňP,]j/0	+7100y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0*H
	1 0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
	*H
^ 
> 8A|r8>vbA4$IU	+ u \
> XBJgq3	wc"˥Gۺ'>>ӕh3+,y`iv7)(~3
8DYf;m)dsvSI~zva_8lpaXӿIܣEɄDAsk9vk7A8e2JL'gH&k! \
m8h#L(⮁qe>3+#`ח


______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic