9 Replies Latest reply on Sep 18, 2007 8:12 AM by Tim Fox

    Cluster - Destination SecurityConfig Lost

    Aslak Knutsen Master

      It seems that a Destinations SecurityConfig is never transferred to the other nodes in the cluster,
      leaving the destination wide open or unusable depending on the DefaulSecurityConfig of the ServerPeer.

      Unless I have missed something, this is probably a bug and not by design.

      Should I add a Jira case ?

      I could start working on it if wanted..

      Should be as 'simple' as getting the qeues SecurityMetaData from the deploying ServerPeer,
      sending it as part of the MappingInfo, and adding it to the receiving ServerPeer.

      -aslak-

        • 1. Re: Cluster - Destination SecurityConfig Lost
          Tim Fox Master

          Aslak-

          Not sure what you mean by the destination security config is never transferred.

          The security config for a destination on a node should be picked up from the xml file that is used to deploy the destination on that node.

          Or maybe you are referring to message suckers? I agree there seems to be a problem there where since message sucker connections are always created with creatConnection() [no params] so if the destination is configured with security this will cause a failure.

          • 2. Re: Cluster - Destination SecurityConfig Lost
            Aslak Knutsen Master

            This issue came up during something that might have been a missconfiguration.
            I was trying to setup a two node cluster where the destinations were only deployed on one node(not using farm),
            figuring that they would be transferred over to the second node.
            InMemoryBindings are added to the second node, but the SecurityMetaData is missing.
            After adding some code to transferred the SecurityMetaData, I found that they are never bound to the DestinationManager,
            so they are never found by any deployed mdbs on the second node.

            I tried a different setup deploying the same destinations on both nodes, that's when I saw this problem:
            http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118320

            When removing the security, it failes on the temporary destination not being bound.
            The scenario is:
            Using the ClusteredConnectionFactory, create a temporary destination on node1.
            Kill node1, the failover to node2 failes because there is no Temporary Destination
            with name X bound in node2s DestinationManager.

            The next potential issue is somehow the connection to the second node has to get the connection id of the first connection, or register itself as the owner of the temporary destination to be able to keep up the tempdestination.createdConnectionId == connection.id security constraint.
            I havn't looked into this yet, it might work already.

            -aslak-

            • 3. Re: Cluster - Destination SecurityConfig Lost
              Tim Fox Master

               

              "aslak" wrote:
              This issue came up during something that might have been a missconfiguration.
              I was trying to setup a two node cluster where the destinations were only deployed on one node(not using farm),
              figuring that they would be transferred over to the second node.
              InMemoryBindings are added to the second node, but the SecurityMetaData is missing.
              After adding some code to transferred the SecurityMetaData, I found that they are never bound to the DestinationManager,
              so they are never found by any deployed mdbs on the second node.


              Any clustered destinations need to be deployed on all nodes


              I tried a different setup deploying the same destinations on both nodes, that's when I saw this problem:
              http://www.jboss.org/index.html?module=bb&op=viewtopic&t=118320

              When removing the security, it failes on the temporary destination not being bound.
              The scenario is:
              Using the ClusteredConnectionFactory, create a temporary destination on node1.
              Kill node1, the failover to node2 failes because there is no Temporary Destination
              with name X bound in node2s DestinationManager.

              The next potential issue is somehow the connection to the second node has to get the connection id of the first connection, or register itself as the owner of the temporary destination to be able to keep up the tempdestination.createdConnectionId == connection.id security constraint.
              I havn't looked into this yet, it might work already.

              -aslak-


              I'm having a bit of a problem understanding your explanation - could you possibly rephrase it?

              • 4. Re: Cluster - Destination SecurityConfig Lost
                Aslak Knutsen Master

                The cluster consist of 2 identical nodes. The Client connects to the Cluster using a ClusteredConnection.
                It then creates a Temporary destination for replyTo on node1. Node1 is killed, and the ClusteredConnection tries a failover to node2, but failes to lookup the Temporary Destination with the following exception:

                30276 [main] ERROR org.jboss.jms.client.FailoverCommandCenter - Failover failed
                javax.jms.InvalidDestinationException: No such destination: JBossTemporaryQueue[f-46mldp6f-1-75lldp6f-izthbc-273333a] has it been deployed?
                 at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createConsumerDelegateInternal(ServerSessionEndpoint.java:1872)
                 at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createConsumerDelegate(ServerSessionEndpoint.java:245)
                 at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createConsumerDelegate$aop(SessionAdvised.java:87)
                 at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
                 at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:123)
                 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                 at java.lang.reflect.Method.invoke(Method.java:597)
                 at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
                 at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
                 at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
                 at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java)
                 at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java)
                 at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100)
                 at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144)
                 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
                 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
                 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387)
                 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
                



                The lookup in createConsumerDelegateIneral is looking for the Destination in the DestinationManager.
                 ManagedDestination mDest = dm.getDestination(jmsDestination.getName(), jmsDestination.isQueue());
                 if (mDest == null)
                 {
                 throw new InvalidDestinationException("No such destination: " + jmsDestination + " has it been deployed?");
                 }
                


                As far as I have debuged; the Temporary Destination MappingInfo is sent to node2 so the Destination
                is bound in memory, but not in the DestinationManager.

                -aslak-

                (if Destinations had been bound to the DestinationManager, shouldn't deploying destinations only on one node also work?)



                • 5. Re: Cluster - Destination SecurityConfig Lost
                  Tim Fox Master

                  By definition, a temporary destination only lives as long as the connection that created it, and only that connection can create consumers on it, so this looks like expected behaviour to me.

                  • 6. Re: Cluster - Destination SecurityConfig Lost
                    Tim Fox Master

                    So just to clarify, the way clustered temporary destinations currently work is as folllows:

                    You create a connection on a node, and create the temporary destination. That temp destination is owned by that connection, and only that connection can create consumers on it.

                    The clustered request / response pattern goes as follows.

                    The connection sends a message to some other destination (non temporary), the message is consumed, and the consumer sends back a reply to the replyTo which contains the name of the temporary destination.

                    The consumer of the non temp destination can be on a *different* node to the sending node - this allows processing to be spread across nodes.

                    The reply can be sent from any node and the reply will make it back to the original sender which is pinned to a particular node.

                    For this to work, the temporary queue can only be consumed by a single connection otherwise the response correlation wouldn't work.

                    • 7. Re: Cluster - Destination SecurityConfig Lost
                      Aslak Knutsen Master

                      I guess this is the behavior that is described as cluster in the Jboss Messaging Documentation.

                      Chapter 7. JBoss Messaging Clustering Configuration
                      ...
                      
                      JBoss Messaging also supports clustered temporary topics and queues. All temporary topics and queues will be clustered if the post office is clustered
                      ...
                      
                      


                      This is just message routing between multiple server nodes..?


                      I would argue that a Clients Connection is with the Cluster, not a specific node within the cluster.
                      The specific node connection is a temporary 'internal' state for the cluster connection.
                      When the Cluster Connection does a failover, the internal state changes,
                      but the Clients ClusterConnection remain the the same.

                      -aslak-




                      • 8. Re: Cluster - Destination SecurityConfig Lost
                        Tim Fox Master

                        By definition, a temporary destination is just that - temporary.

                        It does not survive failover.

                        Non durable topic subscriptions also do not survive failover.

                        The only things that survive failover are persistent messages in either

                        a) non temporary queue

                        b) durable subscription

                        persistent messages in either temporary queues or non durable subscriptions act as non persistent messages.




                        • 9. Re: Cluster - Destination SecurityConfig Lost
                          Tim Fox Master

                          If you want a request, response pattern that *does* survive failover - don't use a temporary reply queue - use a clustered standard (non temporary) queu and make sure the replys are sent as persistent messages.