5 Replies Latest reply on Nov 9, 2007 11:22 AM by joerandom

    Client can connect to Bean before jdbc is bound

    joerandom

      I have an issue with JBoss where clients are connecting to an EJB (2.0) during the server startup before JBoss has bound my jdbc connection to the EJB. This is causing some bad issues in my bean. I've coded around it, but is this the expected behavior during server startup? I would have thought that the EJB would not be accessible until all <env-entry> items have been successfully bound to their respective beans.

      I've searched the forums and the documentation, and have not been able to find anything that specifically addresses this question. Is this expected behavior? Is there some configuration parameter I can use to not allow connections to my EJB before it is fully initialized?

      Below is the relevant part of the log for my server startup.

      2007-10-05 13:38:02,877 INFO :ProxyFactory.java:493 - Bound EJB Home 'ClientApiBean' to jndi 'ClientApiBean'
      2007-10-05 13:38:02,887 INFO :ProxyFactory.java:493 - Bound EJB Home 'JdsInfoBean' to jndi 'JdsInfoBean'
      2007-10-05 13:38:03,107 ERROR:ClientApiBean.java:84 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,107 ERROR:ClientApiBean.java:84 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,117 INFO :EJBDeployer.java:664 - Deployed: file:/proj/jdsdev/test_metrics/xcojdsdev4/env/Misc/jds/release/jds/server/jboss/server/jds/deploy/jdsejb.jar
      2007-10-05 13:38:03,187 ERROR:ClientApiBean.java:84 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,197 ERROR:ClientApiBean.java:109 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,237 INFO :TomcatDeployer.java:126 - deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
      2007-10-05 13:38:03,377 ERROR:ClientApiBean.java:84 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,417 INFO :Http11BaseProtocol.java:156 - Starting Coyote HTTP/1.1 on http-0.0.0.0-9080
      2007-10-05 13:38:03,487 INFO :ChannelSocket.java:387 - JK: ajp13 listening on /0.0.0.0:8009
      2007-10-05 13:38:03,497 ERROR:ClientApiBean.java:84 - javax.naming.NameNotFoundException: jdbc not bound
      2007-10-05 13:38:03,497 INFO :JkMain.java:343 - Jk running ID=0 time=0/30 config=null
      2007-10-05 13:38:03,507 INFO :ServerImpl.java:504 - JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 14s:371ms

      The last line of the log is where I believe the Server is ready for connections (all EJBs have had their resources bound to them). As you can see by the errors, clients are able to lookup the ClientApiBean and perform operations on the bean before the last log line is reached, which means that the "jdbc" entry is not yet bound to the EJB. If I stop all clients, bring the server up, then start all clients, everything runs just peachy.

      Is this the expected startup behavior?

        • 1. Re: Client can connect to Bean before jdbc is bound
          joerandom

          No responses on this yet, but to me this appears to be a bug, and should be logged as such. Before I log it it, does anyone else see this as a bug? Or it this "normal" behavior?

          • 2. Re: Client can connect to Bean before jdbc is bound
            waynebaylor

            why would you run your clients before the server is up?

            • 3. Re: Client can connect to Bean before jdbc is bound
              joerandom

              The clients are crunching numbers, and are always running regardless of the server status. When the clients are done with their number crunching, they try to report their results to the server. If the server cannot be contacted, they simply hold their results and ping the server to see when it comes back up. Once it is detected to be up, they connect to it to report their results, and then they get more numbers to crunch. In this way, I can upgrade the server without losing any work. The issue, again, is that clients can connect to the server during the server startup before the JDBC is bound to the bean, which is causing problems.

              So, back to my original question, has anyone else seen this of think that this is incorrect behavior?

              • 4. Re: Client can connect to Bean before jdbc is bound
                jaikiran

                 

                "joerandom" wrote:
                The issue, again, is that clients can connect to the server during the server startup before the JDBC is bound to the bean, which is causing problems.



                So why not wait for the server to be completely up? This wiki entry shows, how you can programatically check whether the server is up:

                http://wiki.jboss.org/wiki/Wiki.jsp?page=StartupAndDeploymentCheck



                • 5. Re: Client can connect to Bean before jdbc is bound
                  joerandom

                  jaikiran,

                  Thanks for the link, I'll check it out to see if adding this detection logic avoids the issue. However, I still think that I shouldn't have to check to make sure the server is totally up before I can connect to it.

                  For example, assume my clients are running happily. I then decide to bounce my server for some reason (or perhaps my server goes down and needs to be restarted). My clients are unaware of the bounce, and just try to connect to the server as normal when they are done with their calculations (they connect using a remote JNDI lookup). Due to the issue I am seeing, the lookup will be successful, but their first method call on the bean will fail because JBoss has not bound the jdbc entry to my bean yet.

                  Right now I just handle the error on the server and client side and have the client try again later when JBoss has completed deploying my bean. I can certainly add logic to check to make sure the server is up before my clients connect (every time they try to connect), but it really seems like JBoss should not allow remote connections to beans that are not fully deployed. I would rather have the remote lookup fail due to an incomplete deployment of the bean than have it succeed with a bean that isn't completely deployed.

                  I have already handled the issue, so I suppose I'm more talking ideology here, but this doesn't seem to be proper behavior. I don't think that clients should be able to remotely lookup incompletely deployed beans.

                  Anyone else agree, or is this behavior part of the EJB Spec and just needs to be handled?