2 Replies Latest reply on May 1, 2006 1:39 PM by Prashant n

    HAJNDI Access Error via HTTPS from internal VM

    Arnold Hahamyan Newbie

      Hello,

      Using Jboss 3.2.6 I am setting up a cluster of 3 jboss boxes behind a apache load balancer box (via mod_jk2) talking to the coyote AJP connectors on the jboss boxes. I am using the clustering doc (Edition 6). Just to get things started I am only using one of the jboss boxes and the load balancer box. I am using HTTP(S) exclusively for all this. My problem is that when I do a lookup via HAJNDI via HTTPS for a stateless session bean from an external VM things work fine, however I get the following exception when I access the HAJNDI from within the jboss VM the same way.

      EXCEPTIONINFO: classname= class javax.naming.ServiceUnavailableException message= Unexpected failure stacktrace= javax.naming.ServiceUnavailableException: Unexpected failure [Root exception is ReflectionException: Invoke failure
      Cause: java.lang.NullPointerException]
      at org.jboss.naming.interceptors.ExceptionInterceptor.invoke(ExceptionInterceptor.java:56)
      at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
      at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:55)
      at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
      at $Proxy253.lookup(Unknown Source)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:530)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:509)
      at javax.naming.InitialContext.lookup(InitialContext.java:347)
      at com.inphact.common.dac.DacFactory.cacheReportService(DacFactory.java:1677)
      at com.inphact.common.dac.DacFactory.getReportService(DacFactory.java:1646)
      at com.inphact.radweb.application.bricks.mud.ReportImpl.getPrintableReport(ReportImpl.java:374)
      at com.inphact.radweb.navigation.patientdata.ReportBureaucrat.buildPage(ReportBureaucrat.java:124)
      at com.inphact.radweb.navigation.patientdata.PatientDataModuleBureaucrat.activateReport(PatientDataModuleBureaucrat.java:189)
      at com.inphact.radweb.navigation.patientdata.ExamsBureaucrat$ReportEventHandler.processEvent(ExamsBureaucrat.java:262)
      at com.inphact.radweb.navigation.bureaucracy.Bureaucracy.sendUserEvent(Bureaucracy.java:194)
      at com.inphact.radweb.navigation.bureaucracy.Bureaucracy.buildResponse(Bureaucracy.java:83)
      at com.inphact.radweb.navigation.RadwebBureaucracy.buildResponse(RadwebBureaucracy.java:57)
      at com.inphact.radweb.servlets.Radweb.buildPage(Radweb.java:202)
      at com.inphact.radweb.servlets.Radweb.doPost(Radweb.java:134)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
      at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
      at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
      at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
      at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
      at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:80)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
      at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:417)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
      at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
      at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300)
      at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374)
      at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
      at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
      at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
      at java.lang.Thread.run(Thread.java:534)
      Caused by: ReflectionException: Invoke failure
      Cause: java.lang.NullPointerException
      at org.jboss.invocation.http.server.HAInvokerWrapper.invoke(HAInvokerWrapper.java:99)
      at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:149)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
      at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:97)
      at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90)
      at org.jboss.naming.interceptors.ExceptionInterceptor.invoke(ExceptionInterceptor.java:42)
      ... 57 more
      Caused by: java.lang.NullPointerException
      at org.jboss.invocation.http.server.HAInvokerWrapper.invoke(HAInvokerWrapper.java:123)
      at org.jboss.invocation.http.server.HAInvokerWrapper.invoke(HAInvokerWrapper.java:94)
      ... 62 more

      The JNDI properties passed to InitialContext constructor in both the interval and external cases are the following (I am addressing the load balancer box (apache/mod_jk), currently only one jboss in cluster, but in the future there could be many)

      jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.HttpNamingContextFactory");
      jndiProps.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
      jndiProps.put(Context.PROVIDER_URL, "https://192.168.50.209/invoker/HAJNDIFactory");

      I modified the standardjboss.xml in the all/conf directory to include the following

      <invoker-proxy-binding>
      clustered-stateless-http-invoker
      <invoker-mbean>jboss:service=invoker,type=httpHA</invoker-mbean>
      <proxy-factory>org.jboss.proxy.ejb.ProxyFactoryHA</proxy-factory>
      <proxy-factory-config>
      <client-interceptors>

      org.jboss.proxy.ejb.HomeInterceptor
      org.jboss.proxy.SecurityInterceptor
      org.jboss.proxy.TransactionInterceptor
      <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor
      <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor


      org.jboss.proxy.ejb.StatelessSessionInterceptor
      org.jboss.proxy.SecurityInterceptor
      org.jboss.proxy.TransactionInterceptor
      <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor
      <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor

      </client-interceptors>
      </proxy-factory-config>
      </invoker-proxy-binding>

      My beans are set to be clustered as such


      <ejb-name>ReportService</ejb-name>
      <jndi-name>iccr/ReportService</jndi-name>
      <configuration-name>Auth-HTTP Clustered Stateless SessionBean</configuration-name>
      True
      <cluster-config>
      <partition-name>predator</partition-name>
      </cluster-config>


      and use the following container configuration

      <container-configuration extends="Clustered Stateless SessionBean">
      <container-name>Auth-HTTP Clustered Stateless SessionBean</container-name>
      <security-domain>java:/jaas/system-authentication</security-domain>
      <invoker-proxy-binding-name>clustered-stateless-http-invoker</invoker-proxy-binding-name>
      <home-invoker>jboss:service=invoker,type=httpHA</home-invoker>
      <bean-invoker>jboss:service=invoker,type=httpHA</bean-invoker>
      </container-configuration>

      I modified the web.xml at deploy/http-invoker.sar/invoker.war/WEB-INF to add the HAJNDIFactory servlet and its mapping by


      <servlet-name>HAJNDIFactory</servlet-name>
      A servlet that exposes the JBoss JNDI Naming service stub
      through http. The return content is a serialized
      MarshalledValue containg the org.jnp.interfaces.Naming stub. This
      configuration handles requests for the standard JNDI naming service.

      <servlet-class>org.jboss.invocation.http.servlet.NamingFactoryServlet</servlet-class>
      <init-param>
      <param-name>namingProxyMBean</param-name>
      <param-value>jboss:service=invoker,type=httpHA,target=Naming</param-value>
      </init-param>
      <init-param>
      <param-name>proxyAttribute</param-name>
      <param-value>Proxy</param-value>
      </init-param>
      <load-on-startup>2</load-on-startup>



      <servlet-mapping>
      <servlet-name>HAJNDIFactory</servlet-name>
      <url-pattern>/HAJNDIFactory/*</url-pattern>
      </servlet-mapping>

      I also modified the deploy/http-invoker.sar/META-INF/jboss-service.xml to add the following (the invokerURL will be replaced by a Virtual IP Name later on, but the 192.168.50.209 is the address of the load balancer box). I had to start up an apache instance on the jboss server for the time being because I realized that jboss clustered client piece want to communicate with the Jboss instance directly via HTTP whn it is selected as a target. (I will most likely change it to be the coyote https connector in the future)

      <!-- Expose the Naming service interface via HTTP -->

      jboss:service=${partition.name}
      <!-- The Naming service we are proxying -->
      jboss:service=Naming
      <!-- Compose the invoker URL from the cluster node address -->
      https://192.168.50.209/invoker/JMXInvokerHAServlet
      https://
      :443/invoker/JMXInvokerHAServlet
      true
      org.jnp.interfaces.Naming

      ${partition.name}
      org.jboss.ha.framework.interfaces.RoundRobin


      org.jboss.proxy.ClientMethodInterceptor
      org.jboss.proxy.SecurityInterceptor
      org.jboss.naming.interceptors.ExceptionInterceptor
      org.jboss.invocation.InvokerInterceptor




      I very much appreciate any help in solving this problem.

      Thanks

      Arnold

        • 1. Re: HAJNDI Access Error via HTTPS from internal VM
          Arnold Hahamyan Newbie

          I tested the lookup (using HAJNDI) from the server side using the native RMI protocol by using the standard org.jnp.interfaces.NamingContextFactory and a URL of locahost:1100 and the lookup from the server side works fine. Also I tested the same using the auto-discovery feature, by setting the jnp.partitionName as a jndi property and not passing in the provider URL. This also works as well. In retrospect I decided to use the auto-discovery feature from the server side exclusively since that is within the local network and there is little need to use http here. However, it is still a mystery why lookup via HAJNDI using HTTP(S) does not work from Jboss VM. However, the client access to the cluster via HTTP works well. Perhaps someone can benefit from using the config information I posted to get cluster access via HTTP(S) instead of only JRMP/RMI. The whole goal for accessing the HAJNDI from the server side was to lookup a mbean which is a HASingleton which may reside at any box in the cluster, this access is being done using SingletonJMX Invoker (RMIAdaptor) to then lookup the hasingleton mbean, this is very nicely documented in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=55794.

          • 2. Re: HAJNDI Access Error via HTTPS from internal VM
            Prashant n Newbie

            hi arnold,

            can you tell me how did u do that. I am in a jboss(2 nodes) cluster envrionment and each jboss is bound to their loal lan ip.
            If i access my web application, i get an error like this on the console

            2006-05-01 03:16:18,916 DEBUG [org.jnp.interfaces.NamingContext] Failed to connect to localhost:1099
            javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused]]
            at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:254)
            at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1370)
            at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:579)
            at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
            at javax.naming.InitialContext.lookup(InitialContext.java:351)
            at com.mobiapps.servicelocator.ServiceLocator.getRemoteService(ServiceLocator.java:67)
            at com.mobiapps.seakey.responsecenter.ui.login.MobiappsSqlLoginModule.getRemoteHome(MobiappsSqlLoginModule.java:141)
            at


            please guide me how to solve this

            thanks & regards
            shann