Aus MessageDrivenBean entfernte SessionBean aufrufen

[Chrissy09]

Hallo zusammen,

ich versuche vergeblich aus meiner MessageDrivenBean eine SessionBean bzw. deren Methoden auf einem entfernten Server (GlassFish) aufzurufen.

Wenn ich das Ganze nicht aus einer MessageDrivenBean sondern von einem "normalen" Java-CLients versuche, klappt es.
Ich hab genau dengleichen Quelltext genommen:

String URL = "193.43.21.234";
Properties env = new Properties();
env.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory"); 
env.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
env.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
env.put("org.omg.CORBA.ORBInitialHost", URL);
env.put("org.omg.CORBA.ORBInitialPort", "3700");

InitialContext ctx = new InitialContext(env);
ServerSessionBeanRemote ssbr = (ServerSessionBeanRemote) ctx.lookup("jms/ServerTopicSB");
ssbr.sendMessageToLocalTopic("Neue Textmessage");

Die Nachricht kommt an, wenn ich einen normalen Client verwende.
Verwende ich den Code aber in meiner MessageDrivenBean, so ist das lookup noch erfolgreich, aber beim Aufruf der entfernten Methode (letzte Zeile), hängt alles. Die Nachricht kommt nicht an bzw. die entfernte Methode wird nicht aufgerufen.

Was mache ich falsch bzw. was muss ich anders machen, um die Session Bean von einer anderen EJB aus aufzurufen?

Danke.

 

[FArt]

Wo "hängt" es denn? Schon mag gedebuggt? Logging angepasst und Logfiles angesehen? Einen Thread-Dump gezogen?

Der Vorteil bei Open Source Projekten ist, dass der Quellcode verfügbar ist und man wesentlich mehr Informationen sammeln kann als hier bereitgestellt.

Laufen die Server in einem Cluster? Warum bzw. warum nicht? Die gleichen Glassfish-Versionen?
Schon mal gegoogelt? Es gibt eine Menge Doku dazu, wie man Glassfish und JMS in verschiedenen Serverkonstellationen konfigurieren muss.

 

[Chrissy09]

Wo es genau hängt weiß ich nicht, es gibt keine Exception.
Und debuggen in einer EJB gestaltet sich etwas schwierig oder kenne ich nur die Möglichkeit nicht?

Ich habe verschiedene Ausgaben eingefügt und da hat sich halt ergeben, dass der Lookup funktioniert. Das Objekt ist auch nicht null, allerdings beim Aufruf der entfernten Methode hängt dann die Bean. Klar, weil durch das RMI wird sie ja blockiert. Es scheint also so, dass der Methodenaufruf nicht beim entfernten GlassFish bzw. der SessionBean ankommt. Dort habe ich auch eine Ausgabe, aber die wird nie aufgerufen.

Es sind beides die gleichen GlassFish-Versionen und gegooglet habe ich auch schon.
Ich finde nicht mal ein Beispiel, wo jemand eine remote EJB aus einer EJB aufruft. (Zumindest nicht extern - also mit anderer IP).

Komischerweise geht es ja auch, wenn ich lokal bei mir nen Java Client starte (ohne EJB) und dann die entfernte Methode aufrufe. Es funktioniert ja, also wieso nicht aus ner EJB auf eine externe EJB? Vielleicht ist irgendetwas geblockt oder ich muss was einstellen. So viel wie ich gelesen habe, muss es gehen aus einer SessionBean eine andere SessionBean auf einem entfernten Server aufzurufen.

Im Moment versuche ich es ja über den InitialContext aufzurufen. Vielleicht geht nur das nicht in einer SessionBean. Normalerweise injeziert man eine EJB ja über @EJB . Nur dann habe ich das Problem, dass ich nicht weiß wie ich das Ziel, also die IP usw. angeben soll.

Weiß das vielleicht jemand?

 

[FArt]

Prinzipiell spricht nichts dagegen aus einem EJB einen Call auf eine andere Instanz eines AS durchzuführen. Und noch vor Annotations hat man das immer über einen Lookup realisiert, lokal oder remote ;-)

Auf beiden Servern einen Thread Dump ziehen würde dir zeigen, ob der Call lokal bereits hängt oder ob auf der Empfängerseite bereits etwas eingegangen ist, aber noch nicht bei deinem Bean angekommen ist. Den AS selber kann man (wie jede Applikation) hervorragend (z.B. remote) debuggen. Passe das Logging des AS an, so dass du auch das Glassfish eigene Logging ausführlich siehst (bzgl. EJB Container, Remoting, ...)

 

[Chrissy09]

Also das mit den Thread Dumps habe ich gemacht. Aber aus dem Log werde ich nicht schlau. Wonach muss ich denn suchen?

 

[FArt]

Du musst den Thread finden, der dem MDB entspricht (clientseitig). Die Frage ist, wo der gerade steht. Steht der in einem Socket#read0, dann läuft der Call zum Server (weshalb er auch blockiert).
Auf der Serverseite musst du die Threads finden, die eingehenden EJB Calls entsprechen. Einer ist evtl. deiner. Den wieder verfolgen wo er denn ist, steht bzw. was er denn macht.
Es könnte auch sein, dass einer der beiden Threads auf einen Monitor wartet... wird man dann alles sehen.

Es könnte auch sein, dass zwischen den beiden Maschinen noch eine Firewall oder ein Router steht, der den Call verhindert bzw. behindert. Auch darauf kann es Hinweise im Thread-Dump geben.

Nicht zu vergessen: das passende Logging an den Servern!

 

[Chrissy09]

Also ich krieg da nix raus. Wenn ich zb für corba das logging einschalte, kann ich meinen GF nicht mehr starten, weil so viele logs ausgespuckt werden.

Und was hilfreiches kommt auch bei dem thread dump nicht raus.

Für mich ist das ne Suche nach der Nadel im Heuhaufen, da ich nicht weiß was das alles zu bedeuten hat oder was falsch/richtig ist.

Danke trotzdem. Vielleicht hat ja jemand anderes noch eine Idee.

Ne Firewall und was du alles schreibst kann es dohc nicht sein, sonst könnte ich doch auch nicht von nem normalen Client zugreifen.

 

[Hansa]

Hallo,
hast Du für Dein obiges Problem eine Lösung gefunden ?
Ich habe genau das Gleiche und habe schon Tage mit googlen darüber verbracht.
Ich kann beide EJBs direkt ansprechen, aber der indirekte Weg wirft die NamingException.

javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=59;_ThreadName=Thread-1;|javax.naming.NamingException: Lookup failed for 'java:global/SimpleB/SimpleB!sb.SimpleBRemote' in SerialContext[myEnv={org.omg.CORBA.ORBInitialPort=3700, java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, org.omg.CORBA.ORBInitialHost=192.168.56.101, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacesb.SimpleBRemote [Root exception is java.lang.ClassNotFoundException: sb.SimpleBRemote]]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
	at javax.naming.InitialContext.lookup(InitialContext.java:392)
	at javax.naming.InitialContext.lookup(InitialContext.java:392)
	at sa.SimpleA.callB(SimpleA.java:36)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
	at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
	at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
	at $Proxy332.callB(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
	at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
	at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
	at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
	at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
	at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
	at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
	at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacesb.SimpleBRemote [Root exception is java.lang.ClassNotFoundException: sb.SimpleBRemote]
	at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
	at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
	at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
	... 45 more
Caused by: java.lang.ClassNotFoundException: sb.SimpleBRemote
	at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:808)
	at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:696)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	at com.sun.ejb.EJBUtils.getBusinessIntfClassLoader(EJBUtils.java:688)
	at com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(EJBUtils.java:463)
	at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:414)
	... 49 more