Ejb lookup failure : No EJB receiver available for handling ... bla bla combination for invocation context org.jboss.ejb.client

[charlesjg]

Hello all,

I am quite new in jboss AS development, so... sorry if my question is not very clever .

Actually, i am looking for an answer for a while, and I mass googled for that.

here, the trace of my problem:

java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:dao-business-services-1.0-SNAPSHOT,distinctname:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@1fb1fd2

          at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:584)

          at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:119)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)

          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)

          at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)

          at sun.proxy.$Proxy71.getProcessDone(Unknown Source)

I build a small project, stand alone, and the lookup run without any problem. This trace comes from the execution of my lookup inside a Spring controller. (web app, .war). I use jetty for the client app. (websocket support).

here my context building:

        String JBOSS_CONTEXT = "org.jboss.naming.remote.client.InitialContextFactory";

        jndiProperties = new Properties();

        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, JBOSS_CONTEXT);

        jndiProperties.put(Context.PROVIDER_URL, "remote://127.0.0.1:4447");

        jndiProperties.put(Context.SECURITY_PRINCIPAL, "testuser");

        jndiProperties.put(Context.SECURITY_CREDENTIALS, "testpass");

        jndiProperties.put("jboss.naming.client.ejb.context", true);

        jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

        try {

            this.context = new InitialContext(jndiProperties);

        } catch (NamingException e) {

            e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.

        }

and here, an example of lookup:

    public void tryToRetrieveProcessManagerEjb() {

        processManagerRetrieveOk = true;

        try {

            processManager = (ProcessManager) context.lookup("dao-business-services-1.0-SNAPSHOT/ProcessManagerImpl!fr.syneo.traitementdechet.manager.process.ProcessManager");

        } catch (NamingException e) {

            e.printStackTrace();

            processManagerRetrieveOk = false;

        }

    }

Last things:

When i rebuild my context before each ejb lookup, its ok... no "No EJB receiver available for handling bla bla bla " exception.

with someting like that:

                      this.context = new InitialContext(jndiProperties);

                      processManager = (ProcessManager) context.lookup("dao-business-services-1.0-SNAPSHOT/ProcessManagerImpl!fr.syneo.traitementdechet.manager.process.ProcessManager");

and then use the getter of the ejb proxy in my controller.

I really dont get it, and some advice will be greatly appreciated. (sry for english... frenchy dev spotted ).

Thx in advance,

Charles.

[wdfink]

As you use the remote-naming project (remote:// URL) you might run into several issues.

If you can use the created proxy direct after you've create it I suppose the deployment works.

What might happen is that the GC remove the InitialContext from the heap, in this case the connection is closed and the context destroyed.

You need to keep the IC as long as you use the proxy, if you finish the work you should call IC.close().

[charlesjg]

Thx you so much for replying . I feel less alone ...

Wolf-Dieter Fink a écrit:

Thx u so much for your interest

As you use the remote-naming project (remote:// URL) you might run into several issues.

What do you mean ? sorry but... what are the other possibility to set a connection ?

What might happen is that the GC remove the InitialContext from the heap, in this case the connection is closed and the context destroyed.

So what can i do to prevent this behavior ? and what is GC ?

You need to keep the IC as long as you use the proxy, if you finish the work you should call IC.close().

I never call close... and i know it is also a mistake. When a use the "new Context" solution before each ejb call, after sometime, jboss reject connection due to too  much connection (i guess).

[wdfink]

With AS7.1 you can use two approaches

  https://docs.jboss.org/author/display/AS72/EJB+invocations+from+a+remote+client+using+JNDI

  https://docs.jboss.org/author/display/AS72/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project

the recommend one is the first.

GC -> Garbage collector : which remove old unused instances from the memory. In this case the finallize method for Java objects is called

To prevent the problem you need to have a valid reference to the InitialContext as long you will use the proxy which was created by lookup(...)

If you create a lot of InitialContext you might run into connection problems because of the number of opened sockets.

You might have a look to the following projects to find some examples:

https://github.com/wfink/jboss-as-quickstart/tree/ejb-multi-server/ejb-multi-server

https://github.com/wfink/jboss-as-quickstart/tree/ejb-clients/ejb-clients

[charlesjg]

Thx you again.

I will take a look into that.

the recommend one is the first.

The problem is, when i build my small test program (with main etc etc), like your pointed doc (https://docs.jboss.org/author/display/AS72/EJB+invocations+from+a+remote+client+using+JNDI) my code run perfectly.

But when i call my ejb from controller (i use a singleton to retreive all ejb at the start of my web app) i get : No EJB receiver available for handling ...

I will take a look to thes exemples.

Thx again for your time !

Charles.

[wdfink]

That is the problem of the remote-naming as it simplify the use of ejb-client but will miss features.

You might post the code of the singleton ...

[charlesjg]

public class BusinessEjbApi {

    private final String JBOSS_CONTEXT = "org.jboss.naming.remote.client.InitialContextFactory";

    private Properties jndiProperties;

    private Context context;

    private ReportManager reportManager;

    private ProcessManager processManager;

    private CoqueDAO coquedao;

    private OperateurDAO operateurdao;

    private ChariotUtilManager chariotUtilManager;

    private boolean CoqueDaoEjbretrieveOk;

    private boolean OperateurDaoEjbretrieveOk;

    private boolean reportManagerRetrieveOk;

    private boolean processManagerRetrieveOk;

    private boolean chariotManagerEjbretrieveOk;

    public BusinessEjbApi() throws NamingException {

        String JBOSS_CONTEXT = "org.jboss.naming.remote.client.InitialContextFactory";

        jndiProperties = new Properties();

        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, JBOSS_CONTEXT);

        jndiProperties.put(Context.PROVIDER_URL, "remote://127.0.0.1:4447");

        jndiProperties.put(Context.SECURITY_PRINCIPAL, "testuser");

        jndiProperties.put(Context.SECURITY_CREDENTIALS, "testpass");

        jndiProperties.put("jboss.naming.client.ejb.context", true);

        jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

        this.context = new InitialContext(jndiProperties);

        tryToRetrieveChariotManagerEjb();

        tryToRetrieveCoqueDaoEjb();

        tryToRetrieveOperateurDaoEjb();

        tryToRetrieveProcessManagerEjb();

        tryToRetrieveReportManagerEjb();

    }

    public void tryToRetrieveCoqueDaoEjb() {

        CoqueDaoEjbretrieveOk = true;

        try {

            coquedao = (CoqueDAO) context.lookup("dao-business-services-1.0-SNAPSHOT/CoqueDAOJpaImpl!fr.syneo.traitementdechet.dao.coque.CoqueDAO");

        } catch (NamingException e) {

            e.printStackTrace();

            CoqueDaoEjbretrieveOk = false;

        }

    }

    public void tryToRetrieveChariotManagerEjb() {

        chariotManagerEjbretrieveOk = true;

        try {

            chariotUtilManager = (ChariotUtilManager) context.lookup("dao-business-services-1.0-SNAPSHOT/ChariotUtilManagerImpl!fr.syneo.traitementdechet.manager.chariotutil.ChariotUtilManager");

        } catch (NamingException e) {

            chariotManagerEjbretrieveOk = false;

            e.printStackTrace();

        }

    }

    public void tryToRetrieveOperateurDaoEjb() {

        OperateurDaoEjbretrieveOk = true;

        try {

            operateurdao = (OperateurDAO) context.lookup("dao-business-services-1.0-SNAPSHOT/OperateurDaoJpaImpl!fr.syneo.traitementdechet.dao.operateur.OperateurDAO");

        } catch (NamingException e) {

            e.printStackTrace();

            OperateurDaoEjbretrieveOk = false;

        }

    }

    public void tryToRetrieveReportManagerEjb() {

        reportManagerRetrieveOk = true;

        try {

            reportManager = (ReportManager) context.lookup("dao-business-services-1.0-SNAPSHOT/ReportManagerImpl!fr.syneo.traitementdechet.manager.report.ReportManager");

        } catch (NamingException e) {

            e.printStackTrace();

            reportManagerRetrieveOk = false;

        }

    }

    public void tryToRetrieveProcessManagerEjb() {

        processManagerRetrieveOk = true;

        try {

            processManager = (ProcessManager) context.lookup("dao-business-services-1.0-SNAPSHOT/ProcessManagerImpl!fr.syneo.traitementdechet.manager.process.ProcessManager");

        } catch (NamingException e) {

            e.printStackTrace();

            processManagerRetrieveOk = false;

        }

    }

    public boolean isCoqueDaoEjbretrieveOk() {

        return CoqueDaoEjbretrieveOk;

    }

    public boolean isOperateurDaoEjbretrieveOk() {

        return OperateurDaoEjbretrieveOk;

    }

    public boolean isReportManagerRetrieveOk() {

        return reportManagerRetrieveOk;

    }

    public boolean isProcessManagerRetrieveOk() {

        return processManagerRetrieveOk;

    }

    public boolean isChariotManagerEjbretrieveOk() {

        return chariotManagerEjbretrieveOk;

    }

    public OperateurDAO getOperateurdao() {

        return operateurdao;

    }

    public ReportManager getReportManager() {

        return reportManager;

    }

    public CoqueDAO getCoquedao() {

        return coquedao;

    }

    public ProcessManager getProcessManager() {

        return processManager;

    }

    public ChariotUtilManager getChariotUtilManager() {

        return chariotUtilManager;

    }

}

___________________________________________

I use that singleton inside my spring controller.... and it fails. hard.

[wdfink]

From the class it look like that the GC is not the problem as the Context is keept.

I'm not familiar with spring, but if threads are used this can be a problem if the Proxy class is passed to a different thread.

You might give the JBoss API a try. An example can be found here

[charlesjg]

Thx you Wolf,

I got a question: What is the proper pattern to use the ejb so...

If i understand the exemple pointed here

I have to generrate context,

retreive the required ejb,

use the ejb,

and close the context.

But, when the "logic" is outside the SimpleJBossApiClient,

the proper way to close the context is the provide a public methode to close() ?

like:

mySpringController {

fonction1() {

//logic

SimpleJbossApiClient api = new .......

myejb = api.invokeMyEjb();

logic here

api.closeContext();

// mandatory ? i dont get the finally block, it will detroy the context anyway... so...

// is that the proper way to use the exemple "pattern" ?

}

}

[wdfink]

The recommended way for resorces (i.e. sockets, jdbc and other connections) is to close it propper after use.

The InitialContext is the similar to this resources, so you should close it after use. If you have such wrapper the implementation *ApiClient a close() method looks good to me.