Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BB9889879 for ; Tue, 3 Jul 2012 11:05:02 +0000 (UTC) Received: (qmail 2381 invoked by uid 500); 3 Jul 2012 11:05:02 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 2088 invoked by uid 500); 3 Jul 2012 11:05:01 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 2031 invoked by uid 99); 3 Jul 2012 11:04:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jul 2012 11:04:59 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,HTTP_ESCAPED_HOST,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of richard.fallon@atos.net designates 160.92.103.80 as permitted sender) Received: from [160.92.103.80] (HELO smtp1.mail.atosorigin.com) (160.92.103.80) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jul 2012 11:04:50 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp1.mail.atosorigin.com (Postfix) with ESMTP id 8C5FA3800D for ; Tue, 3 Jul 2012 13:04:29 +0200 (CEST) Received: from GBBPX0020.uk.atosorigin.com (gbbpx0020.uk.atosorigin.com [157.203.43.193]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "GBBPX0020.uk.atosorigin.com", Issuer "Entrust Certification Authority - L1C" (verified OK)) by smtp1.mail.atosorigin.com (Postfix) with ESMTPS id 7249F38002 for ; Tue, 3 Jul 2012 13:04:29 +0200 (CEST) X-ME-UUID: 20120703110429468.7249F38002@smtp1.mail.atosorigin.com Received: from ukacpx001.uk.int.atosorigin.com (10.93.225.15) by GBBPX0020.uk.atosorigin.com (10.93.225.11) with Microsoft SMTP Server id 8.1.336.0; Tue, 3 Jul 2012 12:11:20 +0100 Content-Transfer-Encoding: 7bit Importance: normal Priority: normal Received: from UKCWRX004.uk.int.atosorigin.com ([157.203.150.63]) by ukacpx001.uk.int.atosorigin.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 12:04:28 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD590B.9D375D71" Subject: Java Reconnection failure when processing a Message Date: Tue, 3 Jul 2012 12:04:27 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Java Reconnection failure when processing a Message thread-index: Ac1ZC5zeBoLeEQ/XRPeYUUUy4iEoSQ== From: "Fallon, Richard" To: X-OriginalArrivalTime: 03 Jul 2012 11:04:28.0537 (UTC) FILETIME=[9D7D7690:01CD590B] ------_=_NextPart_001_01CD590B.9D375D71 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD590B.9D375D71" ------_=_NextPart_002_01CD590B.9D375D71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, I have a problem when using the java client libraries (0.10). I am connecting to a Qpid broker version 0.8. The problem I have is easy to re-create and has significant impact upon message loss for consuming applications. =20 The problem can be summarised like so:- 1) Start a Qpid Broker 2) Start a Java consumer 3) Send a message to the broker that the consumer will pick-up 4) Stop the Qpid Broker whilst the consumer is processing the message 5) The java consumer will NEVER reconnect Contrast this to=20 1) Start a Qpid Broker 2) Start a Java consumer 3) Stop the Qpid Broker=20 4) The java consumer will always reconnect Or indeed contrast this to=20 1) Start a Qpid Broker 2) Start a Java consumer 3) Send a message to the broker that the consumer will pick-up 4) Stop the Qpid Broker AFTER the message has been processed 5) The java consumer will always reconnect Obviously the impact of this is significant. We have clients who are subscribing to messages and in the event of a Qpid broker outage (if they are processing a message at the time of the outage) they will never reconnect again - without restarting their systems. Whereas other clients may reconnect perfectly well (so long as they were not processing a message at the time of the outage). The net result is message loss as messages are delivered to the exchange whilst the end systems are not subscribing. I have recreated this in a number of environments, I first saw it using Apache Camel, but have since recreated it with a simple POJO. Unfortunately my code is on another network so I have not attached the source for the moment. However detailed below is some pseudo-code which should be easy to recreate. (I initially saw this using Apache Camel - but have removed all Camel references to focus on the issue). //Simple consumer class class MyConsumer { public static void main(String[] args){ while(true) {=20 try { //standard connection stuff connect(); //every time a message is received pause processing receiveMessage(); }//end try catch(Throwable e) { logException(); }//end catch }//end while }//end main public static void receiveMessage(){ while(true) { Message message =3D messageConsumer.receive(TIMEOUT); if(message!=3Dnull{ //got message=20 Thread.sleep(10000); }//end if }//end while }//end receive }//end class The problem appears to be in the invoke method of org.apache.qpid.transport.Session. After a MessageAccept method has been received the application state is such that a sync is never required and the client code never attempts to access the broker again. No exception is thrown up the stack so the client code can't do anything about it. It just loops round internally forever. I have added some code to force the issue in the invoke() method of org.apache.qpid.transport.Session which comes after the existing code if(m.getEncodedTrack() =3D=3D Frame.L4){ } //here's my code if ( state =3D=3DDETACHED && !needSync ) { throw new SessionException("This exception allows clients to know there has been a problem"); } My concern with my "fix" is that I obviously do not understand the full lifecycle methods and different states that the session instance may be in. =20 Could you advise if=20 a) You are aware of this and whether it has been fixed in a later version b) Whether my proposed "fix" will have other adverse side affects? c) Should I send this to a different forum? Thanks for your help Richard <>=20 Richard Fallon Architect 01928 594109 M:+447733312563 E:richard.fallon@atos.net Atos.net <>=20 _______________________________________________________ Atos and Atos Consulting are trading names used by the Atos group. The = following trading entities are registered in England and Wales: Atos IT = Services UK Limited (registered number 01245534), Atos Consulting = Limited (registered number 04312380) and Atos IT Solutions and Services = Limited (registered number 01203466) The registered office for each is = at 4 Triton Square, Regents Place, London, NW1 3HG. The VAT No. for each = is: GB232327983 This e-mail and the documents attached are confidential and intended = solely for the addressee, and may contain confidential or privileged = information. If you receive this e-mail in error, you are not = authorised to copy, disclose, use or retain it. Please notify the = sender immediately and delete this email from your systems. As emails = may be intercepted, amended or lost, they are not secure. Atos = therefore can accept no liability for any errors or their content. = Although Atos endeavours to maintain a virus-free network, we do not = warrant that this transmission is virus-free and can accept no liability = for any damages resulting from any virus transmitted. The risks are = deemed to be accepted by everyone who communicates with Atos by email. _______________________________________________________ ------_=_NextPart_002_01CD590B.9D375D71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Java Reconnection failure when processing a Message

Hello All,

I have a problem when using the java = client libraries (0.10).  I am connecting to a Qpid broker version = 0.8.  The problem I have is easy to re-create and has significant = impact upon message loss for consuming applications. 

The problem can be summarised like = so:-

1)      Start = a Qpid Broker
2)      Start = a Java consumer
3)      Send = a message to the broker that the consumer will pick-up
4)      Stop = the Qpid Broker whilst the consumer is processing the message
5)      The = java consumer will NEVER reconnect


Contrast this to
1)      Start = a Qpid Broker
2)      Start = a Java consumer
3)      Stop = the Qpid Broker
4)      The = java consumer will always reconnect

Or indeed contrast this to
1)      Start = a Qpid Broker
2)      Start = a Java consumer
3)      Send a = message to the broker that the consumer will pick-up
4)      Stop = the Qpid Broker AFTER the message has been processed
5)      The = java consumer will always reconnect

Obviously the impact of this is = significant.  We have clients who are subscribing to messages and = in the event of a Qpid broker outage (if they are processing a message = at the time of the outage) they will never reconnect again – = without restarting their systems.  Whereas other clients may = reconnect perfectly well (so long as they were not processing a message = at the time of the outage).  The net result is message loss as = messages are delivered to the exchange whilst the end systems are not = subscribing.

I have recreated this in a number of = environments, I first saw it using Apache Camel, but have since = recreated it with a simple POJO.  Unfortunately my code is on = another network so I have not attached the source for the moment.  = However detailed below is some pseudo-code which should be easy to = recreate.  (I initially saw this using Apache Camel – = but have removed all Camel references to focus on the issue).

//Simple consumer class
class MyConsumer
{
public static void main(String[] = args){

while(true)
{
try
{
//standard connection stuff
connect();
//every time a message is received = pause processing
receiveMessage();
}//end try
catch(Throwable e)
{
logException();
}//end catch
}//end while
}//end main

public static void = receiveMessage(){

while(true)
{
Message message =3D = messageConsumer.receive(TIMEOUT);

if(message!=3Dnull{

//got message
Thread.sleep(10000);

}//end if
}//end while
}//end receive

}//end class


The problem appears to be in the invoke = method of org.apache.qpid.transport.Session.  After a MessageAccept = method has been received the application state is such that a sync is = never required and the client code never attempts to access the broker = again.  No exception is thrown up the stack so the client code = can’t do anything about it. It just loops round internally = forever.

I have added some code to force the = issue in the invoke() method of org.apache.qpid.transport.Session which = comes after the existing code

if(m.getEncodedTrack() =3D=3D = Frame.L4){
}

//here’s my code

if ( state =3D=3DDETACHED && = !needSync )
{
 throw new = SessionException(“This exception allows clients to know there has = been a problem”);
}

My concern with my “fix” is = that I obviously do not understand the full lifecycle methods and = different states that the session instance may be in. 

Could you advise if
a)      You = are aware of this and whether it has been fixed in a later = version
b)      = Whether my proposed “fix” will have other adverse side = affects?
c)      Should I = send this to a different forum?



Thanks for your help


Richard



3D"Picture
Richard Fallon
Architect
01928 594109
M:+447733312563
E:richard.fallon@atos.net
Atos.net
3D"Picture




Atos and Atos Consulting are trading names used by the Atos = group. The following trading entities are registered in England and = Wales: Atos IT Services UK Limited (registered number 01245534), Atos = Consulting Limited (registered number 04312380) and Atos IT Solutions = and Services Limited (registered number 01203466) The registered office = for each is at 4 Triton Square, Regents Place, London, NW1 3HG.The VAT = No. for each is: GB232327983

This e-mail and the documents = attached are confidential and intended solely for the addressee, and may = contain confidential or privileged information. If you receive this = e-mail in error, you are not authorised to copy, disclose, use or retain = it. Please notify the sender immediately and delete this email from = your systems. As emails may be intercepted, amended or lost, they are = not secure. Atos therefore can accept no liability for any errors or = their content. Although Atos endeavours to maintain a virus-free = network, we do not warrant that this transmission is virus-free and can = accept no liability for any damages resulting from any virus = transmitted. The risks are deemed to be accepted by everyone who = communicates with Atos by email.

------_=_NextPart_002_01CD590B.9D375D71-- ------_=_NextPart_001_01CD590B.9D375D71 Content-Type: image/bmp; name="ole0.bmp" Content-Transfer-Encoding: base64 Content-Description: Picture (Metafile) Content-Location: No%20AttachName Qk1qAAAAAAAAADoAAAAoAAAAgAAAAAMAAAABAAEAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAApGYE AP/////////////////////V1dXV1dXV1dXV1dXV1dXV/////////////////////w== ------_=_NextPart_001_01CD590B.9D375D71 Content-Type: image/bmp; name="ole1.bmp" Content-Transfer-Encoding: base64 Content-Description: Picture (Metafile) Content-Location: No%20AttachName-1 Qk3+EgAAAAAAAH4AAAAoAAAAgAAAACUAAAABAAgAAAAAAAAAAAAAAAAAAAAAABIAAAAAAAAAs4Qw AOfZvwDEoGAA+fXvAKdxEADcxp8AuY1AAO3izwDQs38Af39/AK16IADiz68AoWcAAMqqcADWvI8A ////AL6XUADz7N8AAQEBAQEBAQEBAQ8PDw8PDw8PBwEBAQEBAQEBAQMPDw8PAQgICAgFAQ8PDw8P Dw8DCwgCBggIBw8PDw8PDw8PDw8PAwEOCAgICAgOBw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8IDAwMDAwMDAwMDw8PDw8PDw8GDAwMDAwMDAwMAQ8P CwoMDAwMDAwMBgcPDw8BAgwMDAwMDAwMCggPDw8PDw8BDgAMDAwMDAwMDAwMBA0BDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwgMDAwMDAwMDAwPDw8PDw8P DwYMDAwMDAwMDAwBDw0MDAwMDAwMDAwMDAUPCAwMDAwMDAwMDAwMDAoHDw8DAgwMDAwMDAwMDAwM DAwMDAQFDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PCAwM DAwMDAwMDA8PDw8PDw8PBgwMDAwMDAwMDAELDAwMDAwMDAwMDAwMDAAMDAwMDAwMDAwMDAwMDAwF Dw8ADAwMDAwMDAwMDAwMDAwMDAwNDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8BAQUMDAwMDAsBDw8PDw8PDw8HAQwMDAwMDAUBAwAMDAwMDAwKBgQMDAwMDAwM DAwMDAwMDAwMDAwMDAwBDwEMDAwMDAwMDAwMDAwMDAwMDAwBDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwAMDAwMBQ8PDw8PDw8PDw8LDAwMDAwKDw8BDAwM DAwMDg8PDwUKDAwMDAwMDAYLAw8BDgQMDAwMDAQDDwIMDAwEAAgLAQEOAAwMDAwMDAAPDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDgwMDAwGDw8PDw8PDw8P DwIMDAwMDA4PDwEMDAwMDAIPDw8PDwEMDAwMDAwFDw8PDw8IBAwMDAwMDAIPAQoNBw8PDw8PDw8P BwQMDAwMDAEPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8B DAwMDAwLAQEBAQEBAQEBBAwMDAwMAQ8PAQwMDAwMCw8PDw8PBQwMDAwMDg8PDw8DAAwMDAwMDAwM DAMPDw8PDw8PDw8PDw8PCAwMDAwMAQ8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8ADAwMDAwMDAwMDAwMDAwMDAwMDAAPDw8BDAwMDAwBDw8PDw8ADAwMDAYP Dw8PAwAMDAwMDAwMDAwMBQ8PDw8PDw8PDw8PDw8NDAwMDAwBDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwUMDAwMDAwMDAwMDAwMDAwMDAwMDg8PDwEMDAwM DAEPDw8PDwwMDAwMCw8PDwMADAwMDAwMDAwMDAwADw8PDw8PDw8PDw8PCwQMDAwMDAEPDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PAwwMDAwMDAwMDAwMDAwM DAwMDAwDDw8PAQwMDAwMAQ8PDw8BDAwMDAwPDw8PCAwMDAwMBA4ODAwMDAYPDw8PDw8PDw8PCwYM DAwMDAwMAQ8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P AAwMDAwMDAwMDAwMDAwMDAwMAA8PDw8BDAwMDAwBDw8PDwEMDAwMAA8PDwEMDAwMDAQHDwEMDAwM DA8PDw8PDw8LAgoMDAwMDAwMDAYPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8FDAwMDAoPDw8PDw8ADAwMDAwFDw8PDwEMDAwMDAEPDw8PAQwMDAwKDw8P CAwMDAwMBw8PAQwMDAwEDw8PDwMICgwMDAwMDAwMDAwMBw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwMEDAwMDAcPDw8PAQwMDAwMBAMPDw8PAQwMDAwM AQ8PDw8HDAwMDAwDDw8ADAwMDAIPDw8FDAwMDAYPDw8IBAwMDAwMDAwMDAwMBAsPDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwIMDAwMDQ8PDw8IDAwM DAwCDw8PDw8BDAwMDAwBDw8PDw8MDAwMDAUPDwwMDAwMBw8PDwAMDAwMAg8DAAwMDAwMDAwMDAwM DAIDDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P CwwMDAwEDw8PDwoMDAwMDAsPDw8PDwEMDAwMDAEPDw8PDwAMDAwMAA8BDAwMDAwPDw8HDAwMDAwF DwYMDAwMDAwMDAwMCggBDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PBAwMDAwLDw8HDAwMDAwEDw8PDw8PAQwMDAwMAQ8PDw8PBQwMDAwMAQEM DAwMDA8PAwAMDAwMBAMBDAwMDAwMDAwKDQcPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8NDAwMDAIPDw0MDAwMDAIPDw8PDw8BDAwMDAwB Dw8PDw8PCgwMDAwFAQwMDAwMDwEADAwMDAwIDwIMDAwMDAwKBQ8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwcMDAwMBAMPCgwMDAwM Bw8PAQgICAIMDAwMDAIICAgICA8BDAwMDAgPDAwMDAwABAwMDAwMCgMPBgwMDAwMAg8PDw8PDw8P DwEHDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P DwoMDAwMBQsMDAwMDAoPDw8BDAwMDAwMDAwMDAwMDAwMDw8IDAwMBg8KDAwMDAwMDAwMDAQHDw8G DAwMDAoPDw8PDw8PCAwMDAYPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDQwMDAwAAgwMDAwMDQ8PDwEMDAwMDAwMDAwMDAwMDAwPDw8NDAwEDw0M DAwMDAwMDAwEBw8PDwYMDAwMCg8PDw8PDw8IDAwMBg8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8BDAwMDAwEDAwMDAwBDw8PAQwMDAwMDAwMDAwM DAwMDA8PDw8LBAwLAQwMDAwMDAwMBgEPDw8PDQwMDAwMAg8PDw8PDwgMDAwGDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8ADAwMDAwMDAwMAA8P Dw8HBgYGAAwMDAwMAAYGBgYGDw8PDw8DCAIPAgwMDAwMAAUPDw8PDw8HDAwMDAwMCg0FAQEFBgwM DAYPDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8I CAYMDAwMDAwMDAwODw8PDw8PDw8BDAwMDAwBDw8PDw8PDw8PDw8PDw8DCAgICwEPDw8PDw8PDw8C DAwMDAwMDAwMDAwMDAwMBA8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDwwMDAwMDAwMDAwMDAEPDw8PDw8PDwEMDAwMDAEPDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDwMGDAwMDAwMDAwMDAwMDAwMDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDAwMDAwMDAwMDAwGDw8PDw8PDw8PAQwMDAwMAQ8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8IBAwMDAwMDAwMDAwMDAwPDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8MDAwMDAwMDAwMDAUPDw8P Dw8PDw8BDAwMDAwBDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8DDgYMDAwMDAwMBAYN BQ8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8BAQEBBw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ CQkJCQkJCQkJCQkJCQkJCQk= ------_=_NextPart_001_01CD590B.9D375D71--