Discussion :

[bkinn]

Bonjour à tous,

Voilà, je rencontre un problème intéressant avec RemoteObject, que j'utilise depuis longtemps sans problème, avec un backend Java (GAE) et GraniteDs. Voici la situation :

- j'ai un singleton qui expose une propriété, laquelle "cache" un RemoteObject :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
private var _ro:RemoteObject;
public function get ro():RemoteObject { 
return( _ro ) ? _ro : _ro = getNewRo( "service" ); 
}

- et différentes classes qui effectuent des appels distants, en se servant de cette propriété ro, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var request:AsyncToken = rpcApp.ro.insert( mark, vo );
request.addResponder( new AsyncResponder( roInsertAnswer, roInsertFault, token ) );

Or, lors d'appels successif rapides (boucle de 3 appels "rpcApp.ro.insert( mark, vo );"), j'ai eu la surprise de recevoir ... 3 fois le dernier message émis par le serveur en réponse aux appels. En résumé : call 1, call 2, call 3 retourne 3 fois la réponse du call 3.

Après avoir bien cherché, j'ai fini par désactiver le "cache" RemoteObject, c'est à dire que désormais, j'instancie un nouveau RemoteObject à chaque appel de méthode distante, et désormais tout est ok (call 1, call 2, call 3 retourne bien les réponses des uns et des autres).

Voilà, j'ai bien cherché sans trouver dans google de cas analogue. Est-ce que cela dit quelque chose à l'un d'entre vous ?

Merci, et je profite de ce post pour tous vous remercier pour la qualité de ce site

bkin

[bkinn]

Bon, je crois que j'ai compris ce qui se passe. C'est à fois simple et subtil.
En résumé, chaque RemoteObject (RO) gère en interne une liste des opérations (chacun des RPC effectués), et pour chaque opération, une référence lastResult qui pointe sur la réponse du serveur remote. Une seule référence lastResult pur chaque opération, et non un tableau pour chaque opération ...

Là ou cela devient intéressant, c'est que si, sur un même RO, vous effectuez 3 RPC de même nature successifs (= 3 fois la même opération, par ex RO.getMyList()), le RO initiera bien 3 évènements de réponse, qui référenceront chacun ... le lastResult de l'opération. Si le serveur est rapide, les 3 réponses arriveront avant que vous ne puissiez récupérer le lastResult de la première, de même pour la suivante (c'est là que l'on voit que FLASH est multi thread dans ses opérations internes réseau).

En résumé, vous récupérerez 3 fois la réponse du dernier RPC. Grave !

Solution : créer un new RO pour chaque RPC, au lieu de réutiliser un RO instancié une fois pour toutes. Vu dans un coin que BlazeDS pratiquait ainsi. A déplorer, l'absence de conseil à ce sujet dans les doc Adobe.

Evidemment, tout ce que je décris ici est une pure hypothèse de ma part, qui semble vérifiée par les faits. Donc, n'hésitez pas à donner votre point de vue.