3 Replies Latest reply on Apr 23, 2008 2:46 AM by ron_sigal

    About the usage of path in InvokerLocator

    andyyeung

      Hi, Jboss remoting seems disallowed creation of 2 connectors with 2 InvokerLocators which has same ip and port but different path. Eg
      http://192.168.0.1:8084/Service1
      http://192.168.0.1:8084/Service2.
      It seems the 2 connector cannot started twice with same ip and port as there are Address already in use exception.
      Also when doing client trigger the request to the server. Only transport, ip and port are being matched. Is this a correct behaviour?
      If so, then what is the purpose of having the path for the Locator URL?

        • 1. Re: About the usage of path in InvokerLocator
          mazz

          InvocatorLocators are not "true" URLs, they are "pseudo-URLs" because of things like this.

          Generally, I've found that there really is no "path" to an invocator URL (though they are used when using the servlet transport). You cannot have two locator URLs with the same transport, IP and port and NOT have them point to the same thing (though I guess if you are using the servlet transport, that might work).

          InvocatorLocator URLs do have "query strings" - they are used to set the remoting configuration properties.

          • 2. Re: About the usage of path in InvokerLocator
            beve

            Hi,

            sorry for highjacking your post but I have a similar question...

            We are using JBossRemoting listeners in the JBossESB. There are both socket listeners and http listeners.

            We need to be able to have multiple of these listeners listen to the same host/port combination which we have solved by sharing Connectors and using subsystems to seperate the different listeners. This is so that we don't have to be opening a lot of ports, specially as we have quite a few webservices and more coming.

            The issue we are having is that for webservices we need to have a way to determine which subsystem a http request is for.
            This is easy when the calling client is a JBR client but not when the request is a http request.

            This is what I've been using up until now:
            Code from ServerInvoker's invoke(InvocationRequest)

            Map requestPayload = invocation.getRequestPayload();
            if ( subsystem == null && requestPayload != null )
            {
             String path = (String) requestPayload.get( HTTPMetadataConstants.PATH );
             subsystem = path.substring( path.indexOf( '/' ) + 1 );}
            }
            

            Is there some way we can achive this by configuration of by using some other class in remoting?

            Thanks,

            Daniel

            • 3. Re: About the usage of path in InvokerLocator
              ron_sigal

              Hi Daniel,

              Note that org.jboss.remoting.transport.coyote.CoyoteInvoker is designed to accept input from a client other than org.jboss.remoting.transport.http.HTTPClientInvoker. If it receives a message that is not an InvocationRequest, it will generate an InvocationRequest on the fly, in the method

               protected InvocationRequest createNewInvocationRequest(RequestMap requestMap, ResponseMap responseMap,
               Object payload)
               {
               // will try to use the same session id if possible to track
               String sessionId = getSessionId(requestMap);
               String subSystem = (String) requestMap.get(HEADER_SUBSYSTEM);
              
               InvocationRequest request = null;
              
               boolean isLeaseQueury = checkForLeaseQuery(requestMap);
               if(isLeaseQueury)
               {
               addLeaseInfo(responseMap);
               request = new InvocationRequest(sessionId, subSystem, "$PING$", null, responseMap, null);
               }
               else
               {
               request = new InvocationRequest(sessionId, subSystem, payload,
               requestMap, responseMap, null);
               }
               return request;
               }
              


              So if you can add a HEADER_SUBSYSTEM (actual value "subsystem") header to the HTTP request, it will be treated as the subsystem.

              Does that help?

              -Ron