2 Replies Latest reply on Apr 25, 2006 12:45 PM by mazz

    how best to further identify the server

    mazz

      [for this question - I'm looking more for a "best practices" type answer, if there is such a thing.]

      I am able to auto-detect servers coming online. Network Registry emits notifications that provide information about the newly started server.

      For the most part, all you know about the server is its locator URI.

      How can I determine what "kind" of server it is? Let me define what I mean when I say "kind" of server. As an example, suppose I have two different types of server endpoints - one that processes credit card payments and one that verifies the validity of a customer's social security number (the point is, they are both very different and do different things).

      When one of them comes online, the Network Registry notifies me. But how do I know which server came online? How do I know that the "credit card processor server" was the one that started and not the "customer social security check" server?

      All I have to go on (I think) is the locator URI. Can I put my own "custom" parameters in the locator URI and use that to further identify the server endpoint? For example:

      socket://localhost:1234/?enableTcpNoDelay=false&servertype=CREDITCARD

      notice that in addition to the connector parameters (enableTcpNoDelay) I also gave it my own custom parameter (servertype=CREDITCARD).

      When I detect a new server, the Network Registry notification tells me the locator URI and I just search the URI's path for the parameter that tells me the kind of server it is.

      I actually haven't tried this yet, so I'm not even sure if this trick of adding custom params to the URI is valid, but hopefully you get my point. What is a good way to determine the KIND of server that is at a particular locator URI endpoint?

        • 1. Re: how best to further identify the server

          Is possible to add any custom parameters you like. As long as is not a configuration key for the transport invoker, it will be ignored by remoting.

          The NetworkRegistry fires a org.jboss.remoting.network.NetworkNotification when a server is discovered. The NetworkNotification includes ServerInvokerMetadata which gives the locator uri and array of subsystems. Don't know if subsystems would be enough of an indicator or not.

          Could make code change so could also include the configuration map passed to the server invoker as part of the ServerInvokerMetadata included in the detection message. However, am concerned about allowing free form map for this type of thing as if contains a lot of entries that are not needed, will just be extra traffic on network serving no purpose.

          • 2. Re: how best to further identify the server
            mazz

            I think that's the answer then. If remoting explicitly ignores unknown parameters in the locator URI, then that is probably the best place for me to put my own custom parameters for identification purposes.