Discussion :

[volcon]

bonjour,
j'ai un probleme avec la fabrique des objets distants que je n'ai pas compris.
mon code est le suivant :
public class DaoFactoryImpl extends DaoFactoryPOA{

public DaoIntervenant createDaoIntervenant() {
return (DaoIntervenant) new DaoIntervenantImpl();
}


....


sachant que DaoIntervenantImpl extends DaoIntervenantPOA

mais quand j'appele la methode createDaoIntervenant() coté client, j'obtient l'erreur suivante:

ERROR : org.omg.CORBA.UNKNOWN: ----------BEGIN server-side stack trace----------
org.omg.CORBA.UNKNOWN: vmcid: SUN minor code: 202 completed: Maybe
at com.sun.corba.se.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:8808)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1920)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1870)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1823)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:258)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1682)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1189)
at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:463)
at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:495)
Caused by: java.lang.ClassCastException: dao.DaoIntervenantImpl
at daofactory.DaoFactoryImpl.createDaoIntervenant(DaoFactoryImpl.java:21)
at daofactory.DaoFactoryPOA._invoke(DaoFactoryPOA.java:44)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:637)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:189)
... 9 more

----------END server-side stack trace---------- vmcid: SUN minor code: 202 completed: Maybe
org.omg.CORBA.UNKNOWN: ----------BEGIN server-side stack trace----------
org.omg.CORBA.UNKNOWN: vmcid: SUN minor code: 202 completed: Maybe
at com.sun.corba.se.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:8808)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1920)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1870)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1823)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:258)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1682)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1189)
at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:463)
at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:495)
Caused by: java.lang.ClassCastException: dao.DaoIntervenantImpl
at daofactory.DaoFactoryImpl.createDaoIntervenant(DaoFactoryImpl.java:21)
at daofactory.DaoFactoryPOA._invoke(DaoFactoryPOA.java:44)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:637)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:189)
... 9 more

----------END server-side stack trace---------- vmcid: SUN minor code: 202 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.se.impl.protocol.giopmsgheaders.MessageBase.getSystemException(Unknown Source)
at com.sun.corba.se.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(Unknown Source)
at org.omg.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at daofactory._DaoFactoryStub.createDaoIntervenant(_DaoFactoryStub.java:19)
at clientTest.Client.main(Client.java:105)

Merci d'avance pour votre réponse.

[menator]

Hello,

tu n'indiques pas ton contrat IDL, mais tu es probablement en train de retourner une instance de la classe qui implémente ton DaoIntervenant (DaoIntervenantImpl) alors que l'ORB s'attend à renvoyer une réference d'objet CORBA (DaoIntervenant).

L'implémentation et la référence d'objet sont 2 classes distinctes. Il faut passer par la méthode POA.servant_to_reference() pour passer de l'un à l'autre:
1) on instancie une implémentation
2) on l'active dans un POA
3) on s'adresse au POA pour récupérer la référence d'objet correspondant à l'implémentation et qui pourra être renvoyée en retour de méthode (i.e. publiée à l'extérieur).
(il me semble que POA.servant_to_reference() fait 2) et 3) en même temps, à vérifier).

En cherchant cette méthode sur le forum tu trouveras les exemples.
Il y en a un là:
http://www.developpez.net/forums/d16...-corba-retour/

A vue de nez ça doit être la source de ton problème.
(tout tutoriel correct CORBA décrit la démarche).

[volcon]

bonjour,
merci pour ta reponse, j'ai vu qu'il est logique de faire ça, mais j'ai trouvé pas mal de cours qui utilisent une autre méthode que j'ai dejà utilisé,
dans ce cours, ils instancient l'objet pas (...Impl) et ils la retrournent sans l'activation dans le poa et le reste !!
je te donne un lien de cours qui utilise cette méthode.

http://www.math-info.univ-paris5.fr/....corba-4pp.pdf

aussi j'ai deux autre question:
-quel est l'avantage d'utiliser un factory ?
-Est ce qu'un objet attaché à un POA peut servir plusieurs clients en meme temps (mutitreading) ? ou il faut creer des objets autant de clients ?

merci

[menator]

La manière de faire que tu utilises doit être liée à l'usage du BOA.
C'est toujours utilisable bien que remplacé par le POA, approche sur laquelle je me basais pour te répondre.
Je ne sais plus comment fonctionne l'approche avec BOA, donc pas d'indice à te donner sur le pourquoi de ton erreur.

Pour les avantages d'une factory, je te renvoie vers les présentation du pattern factory sur ce site ou ailleurs. On masque l'origine des objets pour plus de flexibilité et d'adaptabilité: le jour où la manière de créer un objet change, il sera plus facile de modifier une méthode de la factory que de repérer tous les new et de les modifier... Ca c'est la justification quand on programme en local. En mode distant pas de new possible, donc il faut forcément passer par une interface (nommée factory ou autre) si l'on veut commander la création d'objet d'un client vers un serveur.

Oui, un objet attaché à un POA, ou un BOA peut servir plusieurs clients en même temps. C'est ce qui se passera avec une implémentation naïve :
- je crée une implémentation d'objet CORBA + une instance dans mon serveur,
- je diffuse la référence de l'instance CORBA à plusieurs clients,
- mon instance traite toutes les requêtes des différents clients et advienne que pourra

Pour déterminer le comportement concret il faut s'intéresser à la politique de threading de l'ORB utilisé :pool de thread / 1 thread par requête / 1 thread par connection...
Note que le POA dispose d'une politique de Thread : ThreadPolicyValue
- ORB_CTRL_MODEL contrôle laissé à l'ORB
- SINGLE_THREAD_MODEL :1 seul thread par POA
- MAIN_THREAD_MODEL : 1 thread global (pour tous les POAs)

Il me semble que par défaut on est en général en multi-thread, donc ton objet va prendre toutes les requêtes en parallèle. Dans ce cas c'est à toi de protéger ton objet contre les accès concurrents ou bien de sérialiser les requêtes via la bonne ThreadPolicyValue.

C'est là qu'il est important de connaître le nombre d'accès simultanés et la durée des appels dans le cas spécifique de ton application: si les clients sont nombreux mais ne génèrent que peu d'appels simultanés, alors une politique à un seul thread est valable, les requêtes seront sérialisées et tu n'a pas besoin de rendre ton objet thread-safe, sinon il faut jouer plus serré et définir une archi plus robuste.

Là il faut vraiment se renseigner sur la politique de threading de l'ORB utilisé.

[volcon]

mois j'utilise l'ORB du JDK, je sais pas s'il propose des politique de threading.

concernant l'objet que je veux l'attacher à un poa est un objet qui permet le dialogue avec une base des données (supposant quel a une methode create(machin) et delete(machin) ), est ce que deux clients peuvent executer la methode create ou delete parallelement, ou non ?

[menator]

Je vais regarder ce qu'il en est du threading sur l'ORB du JDK.

Sinon ma réponse était: oui, 2 clients vont pouvoir exécuter tes méthodes create() et delete() en parallèle, ce qui va te poser des problèmes de concurrence d'accès. D'où ma digression sur la politique de threading à choisir dans le POA pour éviter ça.
A confirmer en fonction de la politique de threading de l'ORB du JDK.

[volcon]

quel est la différence entre le threading sur l'ORB, et la politique de threading à le POA ?
normalement, si un objet attaché à un POA, on applique la politique sur ce poa non pas sur l'ORB ?

[menator]

C'est ce que je disais plus haut, la ThreadPolicyValue du POA précise si le contrôle est laissé à l'ORB ou si une restriction s'applique pour le POA.

http://www.ciaranmchale.com/corba-ex...-policies.html

Bon visiblement pour le JDK la policy single_thread est à oublier.
http://java.sun.com/developer/techni...eleases/corba/

The ThreadPolicyValue can have the following values:

* ORB_CTRL_MODEL - The ORB is responsible for assigning requests for an ORB-controlled POA to threads.
* SINGLE_THREAD_MODEL - Requests for a single-threaded POA are processed sequentially. (NOTE: This policy is not supported in the ORB shipped with Sun's J2SE v.1.4.1 or higher).

[volcon]

bon d'après ce que j'ai compris ORB_CTRL_MODEL est le threadpolicy par defaut.
et ça permet de traiter des requetes simultanement (concurent).
donc j'aurai pas des problèmes dans mon cas non ?

[menator]

Oui, tu vas probablement être tenté de créer une seule instance d'objet CORBA côté serveur, qui va servir des requêtes de tous les clients.
Donc des accès concurrents sur ton objet serveur vont survenir.

C'est pour cela que je parlais de la SINGLE_THREAD_POLICY (pour un ORB qui le supporterait), ce qui permet de sérialiser les requêtes sur l'objet. (On devrait obtenir le même comportement en réduisant le nombre de thread du thread pool de l'ORB à 1).

Sinon il faut s'intéresser à la protection de l'objet serveur contre les accès concurrents (le rendre thread-safe quoi).

Là je n'ai que de vagues souvenirs...
1) tu peux sérialiser tous les appels en mettant les méthodes distantes "CORBA" synchronized, l'effet sera le même qu'avec une SINGLE_THREAD_POLICY. Les clients risquent un timeout si une requête est trop longue et gêne les suivantes (donc ne fonctionne qu'avec une faible charge et des appels courts).
2) tu peux gérer plus finement le côté thread-safe de l'objet serveur, autoriser les appels simultanés sur les méthodes, utiliser plusieurs connexions à la base de donnée et gérer finement la synchronisation.

[volcon]

je préfère la deuxième solution, comme ça à chaque methode, je vais ouvrir une session (pour la BD) et je fais les traitement et puis je ferme cette session, sachant que la variable session sera une variable locale à la methode: est ce que ça marchera comme ça ?

[menator]

Oui ça devrait fonctionner.
Il sera plus élégant et performant d'utiliser un pool de sessions. A chaque appel tu récupères une session libre auprès de ce pool et il gère la crise en cas de demandes de sessions en parallèle.
Tu économises le coût de création et fermeture des sessions et tu peux dimensionner ce pool en fonction de la charge.
Ca doit exister depuis des lustres dans le monde de la base de données, là je n'y connais rien

Ca peut facilement se faire dans un deuxième temps, une fois que la version simple fonctionne.