1 2 Previous Next 24 Replies Latest reply on Nov 29, 2012 5:37 PM by jayasiv Go to original post Branched to a new discussion.
      • 15. Re: Standalone to remote EJB reconnect issues..
        markus78

        Great, my initial tests seems to work, I will give it some more testing but I think you nailed it.

        • 16. Re: Standalone to remote EJB reconnect issues..
          markus78

          Hello again,

           

          I have tested this some more, sad to say that it still seems broken...

           

          My scenario is ...

           

          A standalone client with "ServerA" and "ServerB" listed in the jboss-ejb-clients.properties file like this

           

           

          endpoint.name=ecs-client-endpoint
          remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
          
          
          remote.connections=Server_A,Server_B
          remote.connection.Server_A.host=localhost
          remote.connection.Server_A.port = 14447
          remote.connection.Server_A.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
          
          
          remote.connection.Server_B.host=localhost
          remote.connection.Server_B.port = 34447
          remote.connection.Server_B.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
          
          

           

          The standalone client tries to invoke on a bean that only exists on Server_A, the client tries to do this every 10 seconds.

           

          Startcondition for client: both servers are down

           

          So I see this in the client logs, fine since the servers are DOWN they cannot be added as EJB receivers..

           

          Testing simple invocation
          createInitialContext()
          Starting
          maj 15, 2012 3:01:26 EM org.jboss.ejb.client.EJBClient <clinit>
          INFO: JBoss EJB Client version 1.0.8.Final
          maj 15, 2012 3:01:27 EM org.xnio.Xnio <clinit>
          INFO: XNIO Version 3.0.3.GA
          maj 15, 2012 3:01:27 EM org.xnio.nio.NioXnio <clinit>
          INFO: XNIO NIO Implementation Version 3.0.3.GA
          maj 15, 2012 3:01:27 EM org.jboss.remoting3.EndpointImpl <clinit>
          INFO: JBoss Remoting version 3.2.4.GA
          maj 15, 2012 3:01:32 EM org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers
          
          WARN: Could not register a EJB receiver for connection to localhost:14447
          java.lang.RuntimeException: Operation failed with status WAITING
                    at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
                    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:119)
                    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:76)
                    at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:77)
                    at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:120)
                    at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
                    at $Proxy0.add(Unknown Source)
                    at my.standalone.standaloneTest.TestInvoke(standaloneTest.java:33)
                    at my.standalone.standaloneTest.main(standaloneTest.java:43)
          
          
          maj 15, 2012 2:50:59 EM org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers
          WARN: Could not register a EJB receiver for connection to localhost:34447
          java.lang.RuntimeException: Operation failed with status WAITING
                    at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
                    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:119)
                    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:76)
                    at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:77)
                    at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:120)
                    at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
                    at $Proxy0.add(Unknown Source)
                    at my.standalone.standaloneTest.TestInvoke(standaloneTest.java:33)
                    at my.standalone.standaloneTest.main(standaloneTest.java:43)
          
          

           

          And the client also fails to invoke on the bean ( since both servers are down )

           

          I start Server_B ( port 34447 in the above example ) and I can see that it is reconnected to with the following printouts in the client log

           

           

          maj 15, 2012 3:02:22 EM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
          INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
          maj 15, 2012 3:02:22 EM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
          INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@7f1e1a8e, receiver=Remoting connection EJB receiver [connection=Remoting connection <a49e885>,channel=jboss.ejb,nodename=ladok-lotho]} on channel Channel ID eb43466c (outbound) of Remoting connection 51037076 to localhost/127.0.0.1:34447
          maj 15, 2012 3:02:22 EM org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver handleMessage
          WARN: Unsupported message received with header 0xffffffff
          
          

           

          But remember my Bean lives on Server_A so I still get errors trying to invoke on it.

           

          Now I start Server_A and.... nothing no connect attempt is ever made to Server_A, it seems like if both servers are down at startup, then the first one to go online will be reconnected to and that's it, the second server is not attempted to reconnect to. And keep in mind that my bean lives on Server_A so my Client keeps throwing "No such EJB receiver" errors...

           

          I have tried this on 7.1.1 and a 7.1.2 nightly ( from 2 weeks ago I think ).

           

          BR

          /Markus

          • 17. Re: Standalone to remote EJB reconnect issues..
            markus78

            I just realised that I have the same name set for my servers..... Sorry to bother you, chaning the server name to unique ones fixed this particular issue atleast with 7.1.2 server, the fault seems to still exist on 7.1.1.

             

            /Markus

            • 18. Re: Standalone to remote EJB reconnect issues..
              jaikiran

              markus78 wrote:

               

              I just realised that I have the same name set for my servers..... Sorry to bother you, chaning the server name to unique ones fixed this particular issue

              Yes that's important to remember.

               

               

              markus78 wrote:

               

              the fault seems to still exist on 7.1.1.

               

               

              I don't see a reason why it should fail against 7.1.1 which is expected to have this fix. Can you make sure you are using the correct EJB client jar version in your client classpath? If that looks fine, then can you get the TRACE level logs of org.jboss.ejb.client on the client side?

              • 19. Re: Standalone to remote EJB reconnect issues..
                markus78

                Hi ,

                 

                I have rerun the testcase with trace levels and figured out why it does not work in 7.1.1 , I see this line ( I have removed the actual nodename though)

                 

                90373 [ejb-client-remote-connection-reconnect-1-thread-8] DEBUG org.jboss.ejb.client.EJBClientContext  - Skipping registration of receiver Remoting connection EJB receiver [connection=Remoting connection <7361b46d>,channel=jboss.ejb,nodename=XXX] since an EJB receiver already exists for node name XXX in client context org.jboss.ejb.client.EJBClientContext@68bd9607
                

                 

                And I get this trace even though I have different server names in the standalone.xml, so in 7.1.1 it seems the node name defaults to the server nodename which must be overriden with the -Djboss.node.name property if you run several instances on the same node , but in the nightlybuild of 7.1.2 the server name attribute from the standalone.xml seems to be used instead (I think the 7.1.2 method is better..), is this correct?

                • 20. Re: Standalone to remote EJB reconnect issues..
                  jaikiran

                  markus78 wrote:

                   

                  so in 7.1.1 it seems the node name defaults to the server nodename which must be overriden with the -Djboss.node.name property if you run several instances on the same node , but in the nightlybuild of 7.1.2 the server name attribute from the standalone.xml seems to be used instead (I think the 7.1.2 method is better..), is this correct?

                  There was this JIRA https://issues.jboss.org/browse/AS7-4110 which handled that change. It says it's fixed for 7.1.1.Final (i.e. the node name should be picked up from the server name attribute of the standalone.xml if it isn't overriden by -Djboss.node.name).

                  • 21. Re: Standalone to remote EJB reconnect issues..
                    markus78

                    I will try to confirm my findings (see if I have a -Djboss.node.name somewhere), but I do have different server names for my two servers , and they are both 7.1.1-Final.

                    • 22. Re: Standalone to remote EJB reconnect issues..
                      markus78

                      As usual you are right, there was a jboss.node.name property hiding in my custom startscripts.

                      • 23. Re: Standalone to remote EJB reconnect issues..
                        jaikiran

                        Thanks for confirming that. On a related note, I think it's time I changed that DEBUG log about skipping the EJB receiver registration to INFO since I've now seen enough users puzzled that their remote node isn't being used.

                        • 24. Re: Standalone to remote EJB reconnect issues..
                          jayasiv

                          Our application is a client server desktop application using EJB. Recently we migrated from JBoss 4.2.3 to JBoss 7.1.1 final. We are getting the same error.

                           

                          WARN: Could not register a EJB receiver for connection to localhost:14447
                          java.lang.RuntimeException: Operation failed with status WAITING

                           

                          Once i restart the JBoss server, it starts working fine again. Not sure if there is any configuration that needs to be done on the server side. Also i see this error messge in the server log appearing several times. When i checked the JBoss forums, it said this issue is fixed in JBoss 7.1.1 final.

                           

                          ERROR [org.jboss.remoting.remote.connection] (Remoting "jboss-p1" read-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host

                           

                          Here is my ejb client property file:

                           

                          endpoint.name=client-endpoint

                          remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

                          remote.connections=default

                          remote.connection.default.host=jboss-p1

                          remote.connection.default.port=4447

                          remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

                           

                           

                          Thanks

                          1 2 Previous Next