RE : [Tsp-devel] Timeout connection tsp_stub_server

[Eric.NOULARD]

J'en ai déjà discuté avec Christophe de vive voix.

jtsp ne gère pas les exceptions par manque de temps dans
la réalisation.

Mon idée première sur les exceptions est d'éviter si
possible de re-traduire des exceptions du genre

OncRcpException  (je sais plus le nom exact)
en
TspConnectionException

sauf si ça apporte qqhose.

Par exemple si on sait qu'une IOException peut arriver
pour des millions de raisons on pourrait faire:

1) je capture IOException
2) je regarde si elle fait l'affaire de la libTSP
   (c'est le cas bubbleling de Stephane)
    OUI: je la 'corrige' si c'est possible
         j'envoie Tsp<XXXX>Exception si le pb ne peut se corriger
    NON: je renvoie la même exception

0) Il est également possible que je n'ai pas à capturer une
exception mais juste devoir déclarer
être capable de la jeter car j'appelle
quelqu'un qui peut la jeter. C'est ce que j'appellerai
laisser passer les bulles.
Ce n'est peut-être pas de bon goût dans le cas
d'exception d'une lib java non incluse dans le JDK
(au cas où on voudrait en changer) mais ça me parrait
"raisonnable" dans bien des cas.

Donc dans jtsp il reste un travail que j'ai remis
à plus tard et que je n'ai donc JAMAIS fait :<<

 - lister les exceptions raisonnables de TSP
 - les implémenter et
 - les utiliser.

J'avais d'ailleurs commencé ça en copiant
(honteusement) une classe de RemoteTea que
vous trouverez quasiment en l'état dans
src/jcore/tsp/core/common/TspException.java

Vous verrez également qu'il y a des /* FIXME throw exception */
(cf TspDataInputStream.java)
et il n'y a qu'un seul endroit ou je jette déjà
UNE malheureuse TspException c'est pour indiquer la fin de flux
dans TspDataInputStream::getData()

Vu mon planning actuel, les contributeurs de tout bord
sont les bienvenus.
Je veux bien jouer le rôle de mainteneur/testeur avant
d'éventuels commit si vous envoyer gentiment vos
patches sous forme de diff CVS sur la liste.

Sinon philosophiquement, Christophe est le premier utilisateur
de jTSP donc sera le "seul" impacté par des changements d'interface
qui seront nécessaire.

Eric

-------- Message d'origine--------
De:     address@hidden de la part de Stephane Galles
Date:   jeu. 29/01/2004 23:34
À:      PECQUERIE, Christophe
Cc:     'address@hidden'
Objet:  Re: [Tsp-devel] Timeout connection tsp_stub_server
Yop,
Puisqu'on parle de jtsp, un autre probléme est l'absence de
remonté d'erreur au démarrage de l'API si le provider
n'est pas la (avec du 'null pointer exception' au tournant)

La raison en est que les exception RPC sont mangées par un try/catch
vide. En fait il faudrait faire, comme d'hab, du 'bubbeling' d'exception
en transmettant cette exception dans une exception Tsp (genre
TspConnectionException).

Peut être même le probleme que tu soulève Christophe est lié à cette
absence de remonté d'erreur.

Je n'ai pas commité ma modif de jtsp (réalisée dans le cadre du
WebConsumer) pour deux raison :
- Nous n'avons pas envisagé pour l'instant des modifs sur jtsp, donc
dans le doute je ne modifie
pas une interface publique...
- Eric est le mainteneur de jtsp et je voudrais son avis sur les modes
de remontés
d'erreur qu'il avait envisagé.
- Je n'ai pas vu d'Exception dans l'API publique de jtsp et j'imagine
qu'Eric
devais avoir une idée dériere la tête pour ne pas en utiliser.

Eric ?







PECQUERIE, Christophe wrote:

>Bonjour, à tous,
>j'ai remarqué qu'il existait une sorte de timeout du coté du provider entre
>le requestInfo et le requestSample.
>Le problème vient du fait qu'une fois ce timeout atteint, toute reception de
>sample est impossible, le stub_server semble bloqué.
>J'ai réussi a reproduire le bug en modifiant un peu jtspStdout.java, j'ai
>rajouté un sleep de 100 secondes entre le requestInfo et le requestSample.
>Ci joint vous trouverez le jtspstdout modifié
>@+
>Christophe
>
> <<jtspStdOut.java>>
> 
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------
>
>CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.
>
>SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.
>
>
>
>This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.
>
>If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.
>
>---------------------------------------------------------
> 
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://mail.nongnu.org/mailman/listinfo/tsp-devel
> 
>




_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-devel