Exceptions beim Aufruf EJB2.1 durch standalone Java

Java-Forum Jakarta EE (Java EE)
1

Hallo,

aus einer Standalone-Anwendung rufe ich eine Bean zur Archivierung aus einer EJB2.1 Anwendung deployed auf JBoss 7.2.0 auf einer anderen Maschine auf.
Ich bin gerade nicht an dem Rechner, so schreibe ich alles aus der Erinnerung. Benötigte Infos reiche ich dann später gerne nach.

Die Aufrufsequenz ist die folgende:

protected String archiv(byte[] data){
  InitialContext ctx = new InitialContext(props);
  ArchivbeanHome abh = (ArchivbeanHome )ctx.lookup(jndistring);
  Archivbean ab = abh.create();
  String result ab.archiv(data);
  ctx.close();
  return result;
}

Der Code funktioniert im Prinzip. Den hab ich so übernommen. Ich darf mich um die Fehlerbeseitigung kümmern und bin kein EJB2-Experte.

Wenn ich close() nicht aufrufe, kommt nach dem 10. Mal eine Exception ala EJB receiver nicht gefunden. Anscheinend wird der context trotz verlassen des scopes nicht garbage collected und die Verbindungen frei gegeben. Ok.
Rufe ich aber ctx.close(); auf, dann bekomme ich eine ThreadPoolException und habe ein MemoryLeak.

Cache ich ctx oder ArchivBean funktioniert alles. Aber dann habe ich die gesamte Reconnectfähigkeit an der Backe und achive ist weder statusfrei noch so einfach threadsafe. Ein connect vor und ein disconnet nach jedem zu archivierenden Dokument wäre mir lieber.

google Abfrage skalieren schlecht. Mal sind fehlende Properties die Ursache. Fehlen aber nicht. Mal sind es andere Gründe, die nicht zutreffen.

Bin für jede Idee und Tipp dankbar.

Gruß und Danke Thomas

2

EJB2.1 ist schon ziemlich hart, da braucht man fast schon Historiker.

Eine Möglichkeit ist sicherlich die Exception, die beim close() auftreten kann zu fangen. Auf ein close() zu verzichten wird wohl schwierig, da der EJB-Container auch nur eine begrenzte Anzahl an Beans bereithält und diese dann irgendwann ausgebucht sind.

Die Frage die sich mir stellt ist, ob da vielleicht noch irgendwie eine Transaktion vorgesehen ist und dies für Probleme sorgt?

Also ob sowas wie das erwartet wird:

UserTransaction tx = …getUserTransaction
tx.begin();
archive…
tx.commit();

3

Hihi.

Das funktioniert nicht. D.h. das funktioniert schon im Prinzip. Aber da läuft der Speicher hoch und es kommt zu einer Out of Memory Exception.

Das schrieb ich oben. Bei 10 ist Schluss. Dann kommt die No EJB receiver Exception.

Interessanter Denkansatz. Hab ich noch nicht verfolgt.
Würde mich aber wundern, wenn das so vorgesehen war. Der Clientcode enthält nichts dergleichen.

4

So mal realen Code auf das Problem minimiert:

final BLWMessageServiceHome blwHome = (BLWMessageServiceHome) blwCtx.lookup(EJB_BLWMessageService);
blwCtx.close();```

Wenn ich die Zeile mit dem lookup drin habe fliegt folgende Exception genau beim Aufruf von close(). Ansonsten nicht. Womöglich wird da lazyhaft nichts gemacht.

ERROR org.jboss.remoting.handler-errors - Close handler threw an exception
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@3cd43368 rejected from java.util.concurrent.ThreadPoolExecutor@f7b100b[Shutting down, pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:110)
at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:432)
at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:59)
at org.jboss.ejb.client.remoting.ChannelAssociation.notifyBrokenChannel(ChannelAssociation.java:404)
at org.jboss.ejb.client.remoting.ChannelAssociation.access$100(ChannelAssociation.java:59)
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:118)
at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:110)
at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:515)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:390)
at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:231)
at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAction(RemoteConnectionHandler.java:376)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
at org.jboss.remoting3.ConnectionImpl.closeAction(ConnectionImpl.java:52)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
at org.jboss.remoting3.EndpointImpl.closeAction(EndpointImpl.java:201)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:153)
at org.jboss.naming.remote.client.EndpointCache.release(EndpointCache.java:61)
at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.close(EndpointCache.java:177)
at org.jboss.naming.remote.client.InitialContextFactory$1.close(InitialContextFactory.java:233)
at org.jboss.naming.remote.client.RemoteContext.close(RemoteContext.java:191)
at javax.naming.InitialContext.close(InitialContext.java:550)
at com.tses.dms.docman.services.ArchiveBLWService.process(ArchiveBLWService.java:87)
at com.tsi.core.services.AbstractWorkloadService.processMessage(AbstractWorkloadService.java:222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at com.sun.proxy.$Proxy28.processMessage(Unknown Source)
at com.bla.core.control.ServiceController$ServiceThread.runProcessing(ServiceController.java:1007)
at com.bla.core.control.ServiceController$ServiceThread.run(ServiceController.java:906)```