7 Replies Latest reply on Jan 28, 2004 7:23 AM by wkraemer

    J2EE Cluster Singleton with failover

    wkraemer

       

      "wkraemer" wrote:
      "wkraemer" wrote:
      "wkraemer" wrote:
      In our current J2EE-based solution, We use static memory (byte[20000])) inside the VM (mostly read, seldom write). These data are very essential for the application and it's behaviour.

      Due to security policies, we are unfortunately not allowed to store (or replicate) these data
      in the database or on any fileystem.

      Actual, we are working with a single server instance and therefore these objects are just stored as static singletons in the
      memory.

      In our current project, we indent to upgrade our single-server solution to a load-balanced, cluster-based solution. In this
      Question:

      How can we make these data accessible to all cluster nodes (regarding performance)? Each new cluster-node must have access to this data shortly after adding to the cluster. How do cluster nodes receive data changes?

      here is an excerpt of the solutions we discussed and that do not seem to meet our requirements:

      - Store Objects in the HA-JNDI Tree
      Because our objects are small, we could save them into the replicated JNDI tree of the application server cluster.
      However, if the host server goes down, the custom object is removed from the cluster's JNDI tree.

      - Use RMI Object
      Use a RMI Object an store the binding (RMI stub) in the HA JNDI. The (single) Remote Object will be available from all nodes in the cluster.
      As with the other solution if the host with the rmi object dies, our information is
      lost.

      - Singleton Service
      Store the object in a singleton service which can be accessed from all nodes. Unfortunately the information is lost, when failover occurs...

      I would be happy about any idea,

      Wolfgang



        • 1. Re: J2EE Cluster Singleton with failover

           

          "juha@jboss.org" wrote:
          "juha@jboss.org" wrote:
          "juha@jboss.org" wrote:
          I'm slightly confused by your question. You say you're not allowed to replicate this data due to security concerns, but how else are you going to share it with other cluster nodes? If you are allowed to replicate it, why cannot you use the existing components that support state replication?



          • 2. Re: J2EE Cluster Singleton with failover
            darranl

             

            "darranl" wrote:
            "darranl" wrote:
            "darranl" wrote:
            As a second point using a static variable to hold the reference to the array is also a bad idea as there are no gurantees that the application server will not use multiple class loaders which would give you multiple instances of the array.


            • 3. Re: J2EE Cluster Singleton with failover
              wkraemer

               

              "wkraemer" wrote:
              "wkraemer" wrote:
              "wkraemer" wrote:
              I'm sorrying for beeing mistakable. Our security policies allow us to replicate, but only between the application server nodes itself and not via the database.

              Which components can I use that replicate the state of an object that is not linked to a client session? (Without database replication, but with failover)

              darranl: you are right. Actually we do not use a static array. We use a Hashtable that stores about 200 Instances of javax.crypto.SecretKey which again includes Keys with a size of about 100 bytes. (That's why I talked about 200x100 = 20000 bytes). Is it still possible, that I get multiple instances of these objects, due to multiple class loaders? How can I get around that? Perhaps I should search for this topic in one of the other forums here.


              • 4. Re: J2EE Cluster Singleton with failover

                 

                "juha@jboss.org" wrote:
                "juha@jboss.org" wrote:
                "juha@jboss.org" wrote:
                Maybe the <a href="http://www.cocoonhive.org/articles/jboss/20030610/hasingleton.html">HASingleton</a> will work for your case.



                • 5. Re: J2EE Cluster Singleton with failover
                  wkraemer

                   

                  "wkraemer" wrote:
                  "wkraemer" wrote:
                  "wkraemer" wrote:
                  Yes, the HASingleton (I refered to it as SingletonService) seems to be almost what we need. Unfortunately (if I understood it right), if a failover occurs, the state of the old master is lost and the service is started with the initial state on another cluster (backup) node. But it is very important for us, that the state is replicated to the backup node.


                  • 6. Re: J2EE Cluster Singleton with failover
                    yaronr

                     

                    "yaronr" wrote:
                    "yaronr" wrote:
                    I wouldn't replicate secret keys if I were you. I bet that if I take 30 minutes, I can write something that will listen to multicast communication and expose those keys.

                    In fact, the prevalent approach to this problem is to store a hash value of the password, and never to store the password itself. That way, you can verify that someone gave you the correct key, but even if someone steals the hash value he can never find the original password (or any password that will work).
                    Of course, you need to use a cryptographic hash function.

                    (this has nothing to do with JBoss, however. It's basic security principles. I hope I'm helping :-) )


                    • 7. Re: J2EE Cluster Singleton with failover
                      wkraemer

                       

                      "wkraemer" wrote:
                      yaronr: you are right. Actualy we do not use these keys for authentication (we use signature cards for that). We are talking about symmetric keys that are used for some special logging. We have different security areas for the application cluster and the database. It is important for us that no dba can read this keys (thats why we can not use the database), but the communication between the cluster nodes will be protected.