From dev-return-93848-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Sun May 6 18:37:39 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id AEB7A180674 for ; Sun, 6 May 2018 18:37:38 +0200 (CEST) Received: (qmail 63466 invoked by uid 500); 6 May 2018 16:37:32 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 63450 invoked by uid 99); 6 May 2018 16:37:31 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 May 2018 16:37:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2B1BA1A2A28 for ; Sun, 6 May 2018 16:37:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent-io.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id II_WEetzDEBA for ; Sun, 6 May 2018 16:37:27 +0000 (UTC) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 10EC35F1ED for ; Sun, 6 May 2018 16:37:26 +0000 (UTC) Received: by mail-pf0-f178.google.com with SMTP id x9so1797522pfm.2 for ; Sun, 06 May 2018 09:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent-io.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=tOGVz3ZTdCNNFNq2Z9cRS5pniRkomE6hlnh2E4/wNas=; b=rXzomwNIXjT8xYLF+GECbwd+5Ias+xyT/+X7AJhJm/E4sGi1S9iNxaos2xawgVDhjN g5Dh6y1+lD20wcWr0xFd04lPU9iIFkLG1BJKZgd2MOhM6TMzIt+oDE+OdOvI8BOy1x1g ozRPfrPiRWixmhAysRxjQuMtFTDlEN+LUoJ3ceszBPKhmg8MBa4l36n2zx4MDLVOz/3m W+0HyaF3TtntaWCjuIuS1kRGrOA6FdL1xRsljf485gX7PY/fsPt30AIu5PQPGW2H348H NOTKvDYud2B+p16ZoUzcYtYcxLw3mSPMVhmUejNqilDIAGIYWWtBjluB3YYjio433Rfo Lzuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:user-agent:mime-version:in-reply-to; bh=tOGVz3ZTdCNNFNq2Z9cRS5pniRkomE6hlnh2E4/wNas=; b=oJRrcwunXz3m05VJsyxYJk++z6Lp7TqpF+3Xe/15TJbpBdBVhZXIl8fnTHChmDbCmx f02mT6V4wr7dgIPhsWU4e+Y1bmcrT12lIwsrUFS73mlfNqG2/OtbcgfpNvFd9auuIr7N FZ1ywanSbU5btM2NwBihUYderWraCi4QmFAVxrMBZtbN47+b62fhg+WqXjlf7aGCylvS 7SavwSzi6df1Mnm3CKBExO2hmuL0CwCrqzlbnJI6OkYMjcdQq+W0fKf7lR/28nFmCjQS vnOQORTcHDEpJwN32aZSNv8gqPlSCny8RuddKcMtdqIUUnbFdpCWUYJiRRIvoKpcYGzg hwsQ== X-Gm-Message-State: ALQs6tDrALJ6vuqI45UfG1BrsOFvh9zXJT8hErdvMpZmTHob0YYjQWzg EntUoy2pa6a6B8kkt6VOj+4jFubNrPE= X-Google-Smtp-Source: AB8JxZrotmCoVrfCC3mQCvZ6YxPEDDsKKkWoce/za3gFLfZW/uaX0pjn3Hcd8GwZ8IV4X1SZPJEx4w== X-Received: by 2002:a17:902:7406:: with SMTP id g6-v6mr17973554pll.237.1525624644075; Sun, 06 May 2018 09:37:24 -0700 (PDT) Received: from Matthias-Sax-Macbook-Pro.local ([2601:647:4a03:2600:24b1:f291:5eec:dd5e]) by smtp.gmail.com with ESMTPSA id k84sm38304143pfh.93.2018.05.06.09.37.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 May 2018 09:37:22 -0700 (PDT) Subject: Re: [DISCUSS] KIP-280: Enhanced log compaction To: dev@kafka.apache.org References: <2063622216.1377682.1523958070807@mail.yahoo.com> <9c803e82-018c-4941-84e5-39c8033c1a53@CO1NAM05FT003.eop-nam05.prod.protection.outlook.com> <990610900.159449.1524555685143@mail.yahoo.com> <32319B29-AE99-4395-A870-346BBC4B28D6@yahoo.com> <818570469.1055639.1524732268255@mail.yahoo.com> <118832288.1472020.1524820296025@mail.yahoo.com> <1930331815.1501565.1524828021171@mail.yahoo.com> <495321457.2225599.1525073235040@mail.yahoo.com> <1296803397.3043203.1525253790487@mail.yahoo.com> From: "Matthias J. Sax" Openpgp: preference=signencrypt Autocrypt: addr=matthias@confluent.io; prefer-encrypt=mutual; keydata= xsFNBFcGWisBEAD4+gj1tJcLJRckkbZjdJpd1347/Zwndn8R6r2X+YYS5EgwzP5OQHl3Q6jl hAISoqBEfDeTJffsxd1wWL+6wKU4Y7zCkH/3aL/7znOlfaewpgJP3x/naawgvnJ0jlPlJtev MlAbG+9P6aEVxYfML59KBtRKzd6OZbSh0VzCJVCvkslv+LZqR94lhA0rArupqe7EO9DuP4/V bvnDxx1dZFtEK4n4wJYsRkF+TuxGClLcfosfM0oHTZeolus+rJTi7wxrbcTOlTmOMW0Wf9rK AobXsSz838RJenQqe3X0s5EBKCoIdI2SCQiTfcJ2JTVt6Ip1IDuEVqMQmtz7i2l3Rlml0GDa gODehmeMczVIBeO0+cppzOEynjQlWLCbJ8XEjISMI87Ied6DGbEYKLnG4ucRjM//8syKI4T+ Z90Y060jhWxrvr2pGqPPaU3qvIXW1D1mchXE1ba4HOdKb6fA7j5NU47WA2YmWRDhfM4exE0Q mD3Jfjfjyuch2rGhT3twSWHk7v5zlINwOfTIfeXvShqxNzJRFf6MudFnFbgmMTo51LmPcXHz 3tUaRNoky/HRpSxU7h145SgltrKSmYgWUnG4Y3qySyiPVKfBUBi/e5dYTk4Y0NDWGhZxOXCs ZV0NQsuoqFD82LrglwECrcdHd2QaKnIX2eKB7j63dMsexFDjewARAQABzSdNYXR0aGlhcyBK LiBTYXggPG1hdHRoaWFzQGNvbmZsdWVudC5pbz7CwXgEEwECACIFAlcGWisCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAAoJEDwRZiHEirRPWcoP/if/UkALwOvkct/IufpQhJ9qmg/a +QrSkDbPFrkWA7r9aMnaX8C5xuFgFuekT2aMzYYEr3eQwNHeeeEEFUhJQnMsKrjMw55w8+J5 Zhzdg8OKepFT0BOovXzITZcyqBW5JdMjfwEkdztBmPHbvWCCjglSllCvNDorxF1FCYuiL+F3 aBx0SaKaXuNhA4GO2IBY68SQ04ueeSbKbnukyWdAYXObBPBvbcoJXeesX6QvANxSjCqPHRsc czAr1mADzPN58nRXrOYgeonhPROYRlhLyEJM9CnGby/GRb9WfrKFwQVVjpNT0dD9vOvobmEp o4//m6qeXh6xC/egW9vBl63fJNOb/A6T1JdFdU8VWpUofAZtPHE61Y11AmkL7EoY5eUhlL0i jCQ4+K4wERP5NGOBEHe6wfxWoQMnPwnj59N8GylCOMhaVaIYqqRuAssMWyliX8nAj0dO3Hbw EZmBMt/xAAZpXCJU3iDS1G0+fs5LIIBWJodBvjec3DpIlib3PGG6IKPfkwpTfyoStRaPAc+X 085/KhgI8hM1nCxzI/0iQSsuyrJikYcCiB+EukaxTy1TS7O3Ul7Sg6f5f2YXB3jh9rPgZf/C y8iIJDyY+zfJLaYPO3uMEtqW69SWVeLM2viy5pj3MtEzDgC16OLINRdIsibPXRchdv7KN2FZ w4uvgTnZzsFNBFrC7GQBEADRIp0Uj4DUrFn049ki3qTuxanbr+76JUeNZ/WT0EUnBq4+v/fB KCHNQxLJJN3HdQLupcauDYIRAnJg5gB9wOcKgjMXmwZ3F8pX/j8Hmf7CEZPbElh64ZpxkNFc 83k6ZiJ2hsQk6F7K3LvqsvgkKAcfHY/Fd/Xwo4YodrcX0OWr+Szp++FPDIHWpiGNo16uobt8 2xUWN5KW0YPiG2gmvHeGGGVeXScn5I76MpJlt1lRCt/uWrYHYc8rupywIn/wCBwKKoNdXaYL TdVlwUB6wxGjNQphBXej173Pckwx+xwb+1KngWS/I/YXGan7+aBJTfkM2kxACqexsxS8NgUx K1VuELlsZRa2AxpzeSmR6Ev6YAAIwjdgiiuTKc3D9LzSb1zQZJ/xrpRy2OdJEXELCFjil0eM ANQH4jovicaWrSd0EH4Ipk6TXjHpkNnGQ2Oy7kzMcwEvaQxQ4SszOSdqDjwR3vQ5dV7d5RCP 1+9qYzFb/sKpoQi9FK/fVUIcPnIdv12B4uU97Vs+ONrOFl8ER+d36fcpogpyNRWSZIttQ96P +kKOAA2L+BP3UdLpchQu8/t+0BZyVmgySWSo8oJA2qFB6rMa8ZsFQoK8m/z7ukBzx7E9geKK 2ZOpqRawJ8nCiDb1nBmJYwgl6ltWV3utg9nLr5oY+35mhnzUszBSoiZlCQARAQABwsF8BBgB CAAmFiEEV9+AVI/wFUXaxShcPBFmIcSKtE8FAlrC7GQCGwwFCQHhM4AACgkQPBFmIcSKtE9O hA/+N5Da5bZVMyEWXuSoASgEAC8uWzT8cVy78XDoGzlPXfEmtz0YC+sWR4psWWIbDpJOcpKe D2AcNuYl24ida2HE+h09LZq8l9EzWpvI30fR9c5LSrKCQJFHyfla3JRCZPr8yT4oQeMYls/2 hP8tk+R2IeZ2aRxLLXCdyBYbmlhK+3y38XZuvzyxbwIQ0plWB26FgnmQZ1PVcU2lfgs3IYBg Vog8gIfvdqxPdxBnV05yE5WhqcdplTmNXyaV4eU1kNfpIMvuhPo1hVKEAznk6csKQcjYBte5 kBLtJKgYR3/lMU2OhF7nBya2HqSWnwCYk7L7f26t0WIVa8JztLkGcEktHFZHs9i0tqGeUSe5 ydiB2tF07K4g1XftQB4VbDSoogp8InTlf2Bfmad0MRcOnWR8BSKyYxgpMljD5wbFnN975s+F d+avW1umqE0raN/chgWQbZf5365hjcWgDzP+o3Vg1aD37CkrWJ+pMFS/FB9VTBYLAdXQvu7O oT7wtga9MXxH3S/c/C5LtFgVYSwuZhGhmB2cKbTMhwToG6rxREjvcYIOA1afynTpMjlTfIIk QPzqnpk6ZIIpcxq+T+PGoiAwV3XmlpPlJeumA1tBSj4OBqVvHYDObcnQaibBK6fxihTgLQHW 8SyMqdjjZyUaNzN3jxG7826WEzmGIs1Js4gPbSM= Organization: Confluent Inc Message-ID: <7f2ecdc7-c9f0-4066-3b8c-d94c3ae68c54@confluent.io> Date: Sun, 6 May 2018 09:37:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oQ424StSppVqnz4DRSfiGCxRN14mRiA4t" --oQ424StSppVqnz4DRSfiGCxRN14mRiA4t Content-Type: multipart/mixed; boundary="WTjVeS1s9L7s0ewUg934qLikKlzbK0PjX"; protected-headers="v1" From: "Matthias J. Sax" To: dev@kafka.apache.org Message-ID: <7f2ecdc7-c9f0-4066-3b8c-d94c3ae68c54@confluent.io> Subject: Re: [DISCUSS] KIP-280: Enhanced log compaction References: <2063622216.1377682.1523958070807@mail.yahoo.com> <5ad5e19c.1c69fb81.f344c.b745@mx.google.com> <1830856732.1438196.1523969056243@mail.yahoo.com> <1639951266.3041605.1524211556065@mail.yahoo.com> <1939671760.105674.1524475809032@mail.yahoo.com> <9c803e82-018c-4941-84e5-39c8033c1a53@CO1NAM05FT003.eop-nam05.prod.protection.outlook.com> <990610900.159449.1524555685143@mail.yahoo.com> <32319B29-AE99-4395-A870-346BBC4B28D6@yahoo.com> <818570469.1055639.1524732268255@mail.yahoo.com> <118832288.1472020.1524820296025@mail.yahoo.com> <1930331815.1501565.1524828021171@mail.yahoo.com> <495321457.2225599.1525073235040@mail.yahoo.com> <1296803397.3043203.1525253790487@mail.yahoo.com> In-Reply-To: --WTjVeS1s9L7s0ewUg934qLikKlzbK0PjX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, I just updated myself on this KIP. One question (maybe it was discussed and I missed it). What is the motivation to not use the offset as tie breaker for the "timestamp" case? Isn't this inconsistent behavior? -Matthias On 5/2/18 2:07 PM, Guozhang Wang wrote: > Hello Lu=C3=ADs, >=20 > Sorry for the late reply. >=20 > My understanding is that such duplicates will only happen if the non-of= fset > version value, either the timestamp or some long-typed header key, are = the > same (i.e. we cannot break ties). >=20 > 1. For timestamp, which is in milli-seconds, I think in practice the > likelihood of records with the same key and the same milli-sec timestam= p > are very small. And hence the duplicate amount should be very small. >=20 > 2. For long-typed header key, it is arguably out of Kafka's control, an= d > indeed users may (mistakenly) generate many records with the same key a= nd > the same header value. >=20 >=20 > So I'd like to propose a counter-offer: for 1), we still use only 8 byt= es > and allows for potential duplicates due to ties; for 2) we use 16 bytes= to > always break ties. The motivation for distinguishing 1) and 2), is that= my > expectation for 1) would be much common, and hence worth special handli= ng > it to be more effective in cleaning. WDYT? >=20 >=20 > Guozhang >=20 >=20 >=20 > On Wed, May 2, 2018 at 2:36 AM, Lu=C3=ADs Cabral > wrote: >=20 >> Hi Guozhang, >> >> Have you managed to have a look at my reply? >> How do you feel about this? >> >> Kind Regards, >> Lu=C3=ADs Cabral >> On Monday, April 30, 2018, 9:27:15 AM GMT+2, Lu=C3=ADs Cabral < >> luis_cabral@yahoo.com> wrote: >> >> Hi Guozhang, >> >> I understand the argument, but this is a hazardous compromise for usin= g >> Kafka as an event store (as is my original intention). >> >> I expect to have many duplicated messages in Kafka as the overall >> architecture being used allows for the producer to re-send a fresh sta= te of >> the backed data into Kafka.Though this scenario is not common, as the >> intention is for Kafka to bear the weight of replaying all the records= for >> new consumers, but it will occasionally happen. >> >> As there are plenty of records which are not updated frequently, this >> would leave the topic with a surplus of quite a few million duplicate >> records (and increasing every time the above mentioned function is app= lied). >> >> I would prefer to have the temporary memory footprint of 8 bytes per >> record whenever the compaction is run (only when not in 'offset' mode)= , >> than allowing for the topic to run into this state. >> >> What do you think? Is this scenario too specific for me, or do you bel= ieve >> that it could happen to other clients as well? >> >> Thanks again for the continued discussion! >> Cheers, >> Luis On Friday, April 27, 2018, 8:21:13 PM GMT+2, Guozhang Wang < >> wangguoz@gmail.com> wrote: >> >> Hello Luis, >> >> When the comparing the version returns `equal`, the original proposal = is to >> use the offset as the tie breaker. My previous comment is that >> >> 1) when we build the map calling `put`, if there is already an entry f= or >> the key, compare its stored version, and replace if the put record's >> version is "no smaller than" the stored record: this is because when >> building the map we are always going from smaller offsets to larger on= es. >> >> 2) when making a second pass to determine if each record should be ret= ained >> based on the map, we do not try to break the tie if the map's returned= >> version is the same but always treat it as "keep". In this case when w= e are >> comparing a record with itself stored in the offset map, version compa= rison >> would return `equals`. As I mentioned in the PR, one caveat is that we= may >> indeed have multiple records with the same key and the same version, b= ut >> once a new versioned record is appended it will be deleted. >> >> >> Does that make sense? >> >> Guozhang >> >> >> On Fri, Apr 27, 2018 at 4:20 AM, Lu=C3=ADs Cabral >> >> wrote: >> >>> Hi, >>> >>> I was updating the PR to match the latest decisions and noticed (or >>> rather, the integration tests noticed) that without storing the offse= t, >>> then the cache doesn't know when to keep the record itself. >>> >>> This is because, after the cache is populated, all the records are >>> compared against the stored ones, so "Record{key:A,offset:1,version:1= }" >>> will compare against itself and be flagged as "don't keep", since we = only >>> compared based on the version and didn't check to see if the offset w= as >> the >>> same or not. >>> >>> This sort of invalidates not storing the offset in the cache, >>> unfortunately, and the binary footprint increases two-fold when "offs= et" >> is >>> not used as a compaction strategy. >>> >>> Guozhang: Is it ok with you if we go back on this decision and leave = the >>> offset as a tie-breaker? >>> >>> >>> Kind Regards,Luis >>> >>> On Friday, April 27, 2018, 11:11:55 AM GMT+2, Lu=C3=ADs Cabral >>> wrote: >>> >>> Hi, >>> >>> The KIP is now updated with the results of the byte array discussion.= >>> >>> This is my first contribution to Kafka, so I'm not sure on what the >>> processes are. Is it now acceptable to take this into a vote, or shou= ld I >>> ask for more contributors to join the discussion first? >>> >>> Kind Regards,Luis On Friday, April 27, 2018, 6:12:03 AM GMT+2, >> Guozhang >>> Wang wrote: >>> >>> Hello Lu=C3=ADs, >>> >>>> Offset is an integer? I've only noticed it being resolved as a long = so >>> far. >>> >>> You are right, offset is a long. >>> >>> As for timestamp / other types, I left a comment in your PR about >> handling >>> tie breakers. >>> >>>> Given these arguments, is this point something that you absolutely m= ust >>> have? >>> >>> No I do not have a strong use case in mind to go with arbitrary byte >>> arrays, was just thinking that if we are going to enhance log compact= ion >>> why not generalize it more :) >>> >>> Your concern about the memory usage makes sense. I'm happy to take my= >>> suggestion back and enforce only long typed fields. >>> >>> >>> Guozhang >>> >>> >>> >>> >>> >>> On Thu, Apr 26, 2018 at 1:44 AM, Lu=C3=ADs Cabral >> >>> >>> wrote: >>> >>>> Hi, >>>> >>>> bq. have a integer typed OffsetMap (for offset) >>>> >>>> Offset is an integer? I've only noticed it being resolved as a long = so >>> far. >>>> >>>> >>>> bq. long typed OffsetMap (for timestamp) >>>> >>>> We would still need to store the offset, as it is functioning as a >>>> tie-breaker. Not that this is a big deal, we can be easily have both= >> (as >>>> currently done on the PR). >>>> >>>> >>>> bq. For the byte array typed offset map, we can use a general hashma= p, >>>> where the hashmap's CAPACITY will be reasoned from the given "val >> memory: >>>> Int" parameter >>>> >>>> If you have a map with 128 byte capacity, then store a value with 16= >>> bytes >>>> and another with 32 bytes, how many free slots do you have left in t= his >>> map? >>>> >>>> You can make this work, but I think you would need to re-design the >> whole >>>> log cleaner approach, which implies changing some of the already >> existing >>>> configurations (like "log.cleaner.io.buffer.load.factor"). I would >>> rather >>>> maintain backwards compatibility as much as possible in this KIP, an= d >> if >>>> this means that using "foo" / "bar" or "2.1-a" / "3.20-b" as record >>>> versions is not viable, then so be it. >>>> >>>> Given these arguments, is this point something that you absolutely m= ust >>>> have? I'm still sort of hoping that you are just entertaining the id= ea >>> and >>>> are ok with having a long (now conceded to be unsigned, so the byte >>> arrays >>>> can be compared directly). >>>> >>>> >>>> Kind Regards,Luis >>>> >>> >>> >>> >>> -- >>> -- Guozhang >>> >> >> >> >> -- >> -- Guozhang >> >=20 >=20 >=20 --WTjVeS1s9L7s0ewUg934qLikKlzbK0PjX-- --oQ424StSppVqnz4DRSfiGCxRN14mRiA4t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEESn/iOv2tmCkcP0KLVp2sL37kObwFAlrvL0EACgkQVp2sL37k ObwdCw//d3ioG6nHQKj2tnabu4H2OpLB9RtwPRpGDRg5hSvPZ9YldaZrfXfqYYkx FH/ySqKCXyDgYrtO7gfZ6XE/p1d5dnAtmGNk529LsiXTxrsb/PdqCyd9ScRvkk1P Hlk12FK94WNAfSLGO2nNWQW8qUH+ySyaUFp2emfAP2ngB5Qsuu3UPIIAN82tzUB5 zlVGSxQBS0XNteJr6x/5ecVU7bGoCX9UjnrbUMlJJdBZ+ZMGufIHRBTUNEP3rIZb 9byb5OX27Eo/zCDwdoKHa9lK21swpCtbfUrjJlS6n0ZCQseov5bju/a5IhOONJnG MGbg6hZLR9n7n/MgzWKDsEjkNUoK512vzAiLA7POJM6YbaA4y93lAt2/U34rC31p ARkG/sfoGqvjg2QaZ81nmd/zeX77OoHoVL2lTRX/kqzZ60nv5FDeWh0LRSKSjOLS jZ1aFidXQpVu+a+wGm3u1ypATrOdz6CCnP3f2oH+FMOYrA2Z56WjVi3hSm5UKJSE /V93ygI9+ZbWZPErfrB9QHLy5rwhze+r/qR50Bca20BFF8lCWhACKBx89/mwibpP P4332X18+Bzqlc6qjxJkRI537uv4JDN9saLfHq991L3/3+NeT2EskDP3fDYFsRvX 72ick44dJuxr1fXK/fw/f5hwrba8ULP/62z8aSLabcvUrwPoEpw= =vSvw -----END PGP SIGNATURE----- --oQ424StSppVqnz4DRSfiGCxRN14mRiA4t--