1 2 Previous Next 26 Replies Latest reply on Mar 27, 2014 10:10 AM by thiru123

    AS7.1 Provider URL for clustered remote JNDI servers

    ned233

      Distribution:  AS 7.1.0.Final

       

      I have been able to successfully get an InitialContext using remoting, like this:

       

           Properties props = new Properties();

           props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

           props.put(Context.PROVIDER_URL, "remote://server1:4447");

           Context context = new InitialContext(props);

       

      However, we have 2 servers in our cluster.  In previous versions of JBoss, you could just comma-separate the provider URL's, like so:

       

           props.put(Context.PROVIDER_URL, "remote://server1:4447,remote://server2:4447");

       

      When I try this, I get the exception below.  Is there another way to do this now?

       

       

      javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.IllegalArgumentException: destination address may not be null]

                at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)

                at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:117)

                at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)

                at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)

                at javax.naming.InitialContext.init(InitialContext.java:223)

                at javax.naming.InitialContext.<init>(InitialContext.java:197)

                at com.fhlbi.cbs.common.util.RemoteQueueTest.main(RemoteQueueTest.java:34)

      Caused by: java.lang.IllegalArgumentException: destination address may not be null

                at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:98)

                at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:296)

                at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)

                at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)

                at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)

                at org.jboss.naming.remote.client.cache.EndpointCache$EndpointWrapper.connect(EndpointCache.java:110)

                at org.jboss.naming.remote.client.cache.ConnectionCache.get(ConnectionCache.java:41)

                at org.jboss.naming.remote.client.InitialContextFactory.createConnection(InitialContextFactory.java:153)

                at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateConnection(InitialContextFactory.java:126)

                at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:106)

                ... 5 more

        • 1. Re: AS7.1 Provider URL for clustered remote JNDI servers
          rhusar

               props.put(Context.PROVIDER_URL, "remote://server1:4447,remote://server2:4447");

          Nope, thats not how it works in AS7. Context.PROVIDER_URL is not supported. You will need jboss-ejb-client.properties file.

           

          Take a look at the following for how to do it with AS7:

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

          (also might interest you:)

          https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance

          • 2. Re: AS7.1 Provider URL for clustered remote JNDI servers
            ned233

            @Radoslav, thanks for the feedback.  I am not sure your solution agrees with the "remote JNDI" discussion here:  https://issues.jboss.org/browse/AS7-1338

             

            In that discussion, they clearly demonstrate support for Context.PROVIDER_URL (In fact, I currently have it working this way).

             

            We are attempting to integrate a third-party closed system with remote JBoss queues.  The third-party system needs to do a remote JNDI lookup against our JBoss cluster.  That other system expects the following parameters:  provider URL, InitialContextFactory, and ConnectionFactory.  This is a pretty industry-standard way of doing JNDI lookups.  I have this working right now, but I can only specify one server in the provider URL, which means I cannot take advantage of the JBoss cluster.  Taking the approach you linked to would require code changes to the third-party system.  Unfortunately, this is outside our control.

             

            Is there some other way to specify multiple servers within the constraints I have listed?  I would imagine this is a fairly common integration scenario.

            • 3. Re: AS7.1 Provider URL for clustered remote JNDI servers
              wdfink

              Unfortunately there is no other way ATM as I know.

               

              What if you set URL_PKG_PREFIXES and pack the jboss-ejb-client.properties in the API jar or even in a separate one and add it to the third-party classpath?

              I think the PROVIDER_URL can be empty and will be ignored (I'll check if I find the time )

              • 4. Re: AS7.1 Provider URL for clustered remote JNDI servers
                ned233

                Unfortunately, the third-party system is not pulling in a generic jndi.properties file.  They have their own properties file which requires provider URL, InitialContextFactory, and ConnectionFactory (and does not look for any other properties).  So, setting URL_PKG_PREFIXES would require a change to the third-party system, which is something we cannot do. 

                 

                This issue reduces the effectiveness of our entire JBoss cluster now.  Why was a feature removed that previously worked just fine in previous versions?  I have worked with other clients who have the exact same deployment scenarios, and who will run into this very same issue if and when they upgrade.

                • 5. Re: AS7.1 Provider URL for clustered remote JNDI servers
                  rhusar

                  @Radoslav, thanks for the feedback.  I am not sure your solution agrees with the "remote JNDI" discussion here:  https://issues.jboss.org/browse/AS7-1338

                  LOL, things seems to change from week to week :-) All I can say is that the client properties work for now well, but I understand you are feeding this to 3rd party software.

                  Why was a feature removed that previously worked just fine in previous versions?

                  Seems like the main reasoning was the security implications of remote JNDI.

                  • 6. Re: AS7.1 Provider URL for clustered remote JNDI servers
                    ned233

                    Radoslav, I tried the approach you referenced, just to see if it would work.  Here is the relevant code:

                     

                         Properties props = new Properties();

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

                         Context context = new InitialContext(props);

                     

                    I also added the jboss-ejb-client.properties to the classpath.  When I run my test, I get the following error on that last line of code:

                     

                    javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

                              at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)

                              at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)

                              at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)

                              at javax.naming.InitialContext.lookup(InitialContext.java:392)

                     

                    How do you get around receiving this error?

                    • 7. Re: AS7.1 Provider URL for clustered remote JNDI servers
                      jaikiran

                      Are you looking up EJBs or something else. The Context.URL_PKG_PREFIXES = "org.jboss.ejb.client.naming" is only meant for ejb: namespace look ups.

                       

                      Anyway, your original issue about not being able to pass comma separated list of PROVIDER_URLs is because that's not supported. Only a single PROVIDER_URL is currently supported.

                       

                      We are attempting to integrate a third-party closed system with remote JBoss queues.  The third-party system needs to do a remote JNDI lookup against our JBoss cluster.  That other system expects the following parameters:  provider URL, InitialContextFactory, and ConnectionFactory.  This is a pretty industry-standard way of doing JNDI lookups.  I have this working right now, but I can only specify one server in the provider URL, which means I cannot take advantage of the JBoss cluster.  Taking the approach you linked to would require code changes to the third-party system.  Unfortunately, this is outside our control.

                      That isn't exactly clustering, is it? It's just a way to specify multiple URLs of server instances which might not even have clustering capability (for example, multiple individual standalone servers started without the cluster subsystem). The real clustering of queues can only be configured on server side.

                      • 8. Re: AS7.1 Provider URL for clustered remote JNDI servers
                        ned233

                        @jaikiran, thanks for your response.  I am attempting to lookup a JMS ConnectionFactory, but thought I would follow Radoslav's instructions.  As you said, I don't think his option is relevant for JMS.

                         

                        As I understood it (and as Red Hat support explained it to me a couple of years ago), as of version 5.1.0, JBoss required you to specify all of your servers in the provider URL in order to ensure high availability in your JNDI lookups.  This was somewhat awkward, but it worked.  Now that that option is gone, I am searching for another way to achieve this.  You are correct, the clustering is actually done on the server side, but since our third-party system can now only point to one node in the cluster, we have effectively eliminated high availability from our architecture.  If that JBoss node goes down, everything is down.

                         

                        It seems that there is a gap here that has not been addressed.  It appears that our only recourse would be to put a content switch between the JBoss cluster and the third-party system, which is not preferable.

                        • 9. Re: AS7.1 Provider URL for clustered remote JNDI servers
                          jaikiran

                          Ed Keen wrote:

                           

                          You are correct, the clustering is actually done on the server side, but since our third-party system can now only point to one node in the cluster, we have effectively eliminated high availability from our architecture.  If that JBoss node goes down, everything is down.

                           

                          It seems that there is a gap here that has not been addressed.

                          From a client point of view, yes, that's true. The ability to pass multiple comma separated PROVIDER_URL is something that perhaps we could add support for, but I haven't yet discussed this with others and it does have atleast one implication that I can think of. I'll discuss the possibility of adding the support for this. Whether or not it's supported will depend on the outcome of the discussion. I'll file a JIRA (or ask you to) if we decide to support this. But I wanted to make sure that you and others reading this thread understand that adding such a feature has nothing to do with clustering. Based on your answer I understand that you are aware of this.

                           

                           

                          Ed Keen wrote:

                           

                           

                           

                          As I understood it (and as Red Hat support explained it to me a couple of years ago), as of version 5.1.0, JBoss required you to specify all of your servers in the provider URL in order to ensure high availability in your JNDI lookups. 

                          Someone with more knowledge of how JMS destination clustering is currently setup in AS7 might be able to help you with that part.

                          • 10. Re: AS7.1 Provider URL for clustered remote JNDI servers
                            jbertram

                            To be clear, in previous versions of JBoss AS (which use HA-JNDI) it isn't strictly necessary to specify a list of URLs.  You can completely leave out the java.naming.provider.url and rely on discovery (optionally specifying the appropriate jnp.partitionName).  See more here.

                            • 11. Re: AS7.1 Provider URL for clustered remote JNDI servers
                              jbertram

                              Someone with more knowledge of how JMS destination clustering is currently setup in AS7 might be able to help you with that part.

                              The JNDI lookup of JMS resources (and whether or not that is done in a highly-available fashion) is completely independent of the behavior of those JMS resources once the look-up is complete and the client is actually using them.  At that point, HornetQ semantics take over.  HA for HornetQ is provided by live/backup server groups, but I digress.

                              • 12. Re: AS7.1 Provider URL for clustered remote JNDI servers
                                ned233

                                Justin Bertram wrote:

                                 

                                You can completely leave out the java.naming.provider.url and rely on discovery (optionally specifying the appropriate jnp.partitionName).

                                 

                                I wish we could take advantage of this.  The only problem is, this client does not allow UDP multicast traffic at all.  I seem to work for clients in highly regulated industries, and have never seen UDP allowed at any of them, and they always cite security as the reason.  <sigh>

                                • 13. Re: AS7.1 Provider URL for clustered remote JNDI servers
                                  rhusar

                                  and have never seen UDP allowed at any of them, and they always cite security as the reason.  <sigh>

                                  Just curious, what exactly is the security reason if its used for autodiscovery?

                                  • 14. Re: AS7.1 Provider URL for clustered remote JNDI servers
                                    ned233

                                    Apart from UDP being somewhat "chatty" on the network, the network admins that I have worked with do not like UDP traffic because they claim it could enable the introduction of a "rogue" server into the cluster, which could then do malicious things.  At one client, someone actually (accidentally) joined the live production cluster by starting JBoss locally on their developer workstation.

                                    1 2 Previous Next