[Bitrepository-devel] Protokol-præciseringer

Thu Jun 30 10:33:02 CEST 2011

Hej,

Vi kan sagtens lade være at checke for sanity i produktion. Men det vil
jo ikke ændre på at der potentielt er mulighed for at de er forskellige.
Men jeg er nok enig i at det ikke skal være et krav at man checker. Men
vi bør nok lave en anbefaling af hvad man skal gøre hvis man oplever
forskelle/fejl.

Umiddelbart hælder jeg til at XML har ret, og kopierne i headers primært
er ekstra information der kan bruges af ActiveMQ til at route dem.

Hilsen
  Kåre

On Fri, 2011-06-24 at 14:42 +0200, Jun Petersen Yoneyama wrote:
> Hej
> 
> Er sanitycheck en debug mekanisme eller vil I også bruge den i produktionskoden og i den åbne kode til referenceimplementationen?
> 
> Det sidste lyder ikke rigtig i mine ører.
> I princippet bør det kunne fungere alene ved at dekode XML beskeden. Kopier i JMS headeren er kun til for at gøre det nemmere at programmere.
> Men benytter man sig af JMS headeren, så bør det i praksis være godt nok.
> (Bortset fra de felter, der er nyttige for JMS/ActiveMQ)
> 
> Hvis vi alligevel skal sammenligne JMS headeren med XML, så synes jeg det er nemmere bare at tage det hele fra XML.
> 
> Men sanitychek under test/debugging er klart nyttig
> 
> Med venlig hilsen
> 
> Jun
> 
> 
> 
> -----Oprindelig meddelelse-----
> Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Kåre Fiedler Christiansen
> Sendt: 24. juni 2011 13:23
> Til: bitrepository-devel at ml.sbforge.org
> Emne: [Bitrepository-devel] Protokol-præciseringer
> 
> Hej,
> 
> Ved implementationen af Get har vi identificeret følgende ting som vi
> ikke synes er helt klare når vi skal implementere.
> Nogle af dem er fordi den del af protokollen ikke er helt færdig, andre
> mangler vi måske blot at tage stilling, eller skrive en stilling vi
> allerede har taget ned.
> 
> Emnerne kommer i fire klumper.
> 
> === Behandling af beskeder ved modtagelse ===
> 
> Når vi modtager en besked, er der nogle måder vi skal opføre os på, som
> for nogle vist er aftalt, men jeg ikke er sikker på hvor er skrevet ned;
> og hvor andre er noget hvor vi blot skal have taget stilling.
> 
> 1. Modtagelse af beskeder hvor pillar IDs ikke svarer til os
> 
> Jeg tror det er vores aftale at de blot skal ignoreres, men er det
> skrevet ned noget sted?
> 
> 2.  Skal man sanityChecke de elementer der både findes i JMS headers og
> beskeden. Hvad skal man gøre hvis de er forskellige? (CorrelationID,
> BitRepositoryCollectionID, ReplyTo, To (kan sammenlignes med
> destinations man lytter på), type)
> 
> Jeg synes det vil være en god idé at sanitychecke - men jeg er ikke
> sikker på hvordan det skal håndteres.
> Hvad vi skal gøre hvis checket fejler? Jeg foreslår vi blot logger en
> fejl lokalt og fortsætter. Jeg foreslår at det blot er en anbefaling til
> pillar, og ikke et krav.
> Hvem "vinder" hvis headeren er uenig med beskeden? Jeg foreslår beskeden
> altid vinder (dog ikke med "To" - den er jo allerede modtaget). Det
> synes jeg vi skal gøre til et krav.
> 
> 3. Hvad skal man gøre hvis der ikke er et correlationID i beskeden?
> 
> Ignorer? Generer et correlationID? Benyt JMS message ID? Jeg foreslår vi
> anbefaler at man benytter JMS message ID men ikke gør det til et krav.
> 
> === Svar med "fejlkoder" og alarmer ===
> 
> Her er vi vist ikke helt klar med specifikationen - men kan vi tage
> nogle første her-og-nu valg?
> 
> 1. Der er et fundamentalt problem lige nu, med at
> IdentifyPillarsForGetFile ikke kan sende fejlkoder med i svaret. Det er
> vist i modstrid med hvad vi har aftalt, da vi ønsker at pillars kan
> svare selvom de ikke har filen, så klienter ikke skal vente på et
> timeout.
> 
> 2. Lige nu tror jeg det eneste sted der er en specifikation af mulige
> fejl-koder er i Eld's proof-of-concept-fejlkoder i XSD'erne. Det ville
> være godt at få et sted at vedligeholde en liste af hvad der er og
> hvornår det skal bruges.
> Tilsvarende med hvilke alarmer der skal sendes hvornår.
> 
>  * Her er en liste af potentielle "Negative svar" og alarmer vi har
> identificeret
>    * Potentielle negative svar på enhver besked
>       * Ukendt BitRepositoryCollection
>       * Uunderstøttede versioner (også alarm?)
>       * Ugyldig XML (også alarm?)
>       * Fejl i sanitycheck - se ovenfor (også alarm?)
>       * Intet correlation ID - se ovenfor (også alarm?)
>       * Intern pillar-fejl forhindrer behandling (også alarm?)
>    * Potentielle negative svar ved IdentifyPillarsForGetFile
>       * File not found
>    * Potentielle negative svar ved GetFile
>       * File not found
>       * Del af fil requested men ikke understøttet
>       * Ingen/ugyldig URL angivet til at levere fil på
>       * Problemer med at uploade filen til den givne URL (også alarm?)
> 
> 3. I hvilke beskeder skal man sende fejlkoder? Jeg forventer at en
> fejlkode betyder at konversationen er afsluttet for den pillars
> vedkommende, og de derfor ikke skal sendes i
> "ProgressResponse"-beskederne, som indikerer status undervejs, men
> derimod i "FinalResponse"-beskederne.
> 
> === TimeToDeliver ===
> Jeg tror vi har aftalt at time-to-deliver er optional, men hvis den angives er det den forventede tid før man kan begynde at levere - men er det skrevet ned nogen steder?
> 
> Vi har også snakket om at man kan give opdaterede estimater i ProgressResponse-beskeder. Men det kan på nuværende tidspunkt ikke sættes i beskeden.
> === Request af flere filer i én GetFile-besked ===
> 
> Det er noget vi har snakket om nogen gange, men jeg ved ikke rigtig hvor
> vi står.
> 
> Er der et use case for det? Eller skal vi blot droppe understøttelsen
> helt. Jeg tror det er mig selv der har foreslået det for at kunne
> gruppere requests til at brunge offline-medier online, men det kan i
> virkeligheden klares lokalt på en pillar - på SB tape pillar'en husker
> vi filer der er requested, men genererer kun et job til at bringe dem
> online med passende mellemrum. Det giver samme effekt.
> 
> Hvis vi skal understøtte det mener vi der er et problem i at der er kun
> én URL i beskederne, så vi ved ikke hvordan man skal levere flere filer.
> 
> Hilsen
>   Kåre
> 
> 
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel