Local Queue in a cluster

          Hi
          Is there any way to programmatically determine whether a queue is local to a server
          in a cluster. Like for example there are 3 server in a cluster and I have pinned
          the Queue to a server say server#3. Now I want to start some processes in that
          server which hosts the Queue - and not in any other server - like a polling program.
          So somehow that has to detect that the Queue is local to that server though the
          JNDI name is replicated in the cluster ie all members in the cluster should be
          able to see the Queue.
          thanks
          Anamitra
          

          You can look up the queue using createQueue() with the syntax
          "./queue-name". This looks for queue's running on the same
          server as the client's host connecton. (A client running
          on a server will host its connection on the same server
          provided the client's connection-factory contains the server
          in its target list...). This syntax is supported by 7.0,
          6.1SP3 or later, and 6.1SP2 with patch CR072612.
          You can turn off JNDI name replication for the destination.
          This feature is not exposed on the console until 8.1, but you can
          set it in the destinations config.xml via:
          JNDINameReplicated="true"
          This may not work on all versions, if this doesn't work (eg it
          generates a syntax error), contact customer support. There
          are enhancement patches...
          In WebLogic 8.1 you can query the queue object to determine
          the related mbean. Then get the parent's parent
          to determine the server-name. (see weblogic.jms.extensions.JMSHelper)
          You other versions you can get the mbeans as well. If you
          use the "local" mbean-home, it restricts the view to
          runtime mbeans that are running on the same server as
          the supplied context:
          if (useLocalMBeanHome)
          mbh = (MBeanHome)ctx.lookup(MBeanHome.LOCAL_JNDI_NAME);
          else
          mbh = (MBeanHome)ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
          Tom
          Anamitra wrote:
          > Hi
          > Is there any way to programmatically determine whether a queue is
          local to a server
          > in a cluster. Like for example there are 3 server in a cluster and I
          have pinned
          > the Queue to a server say server#3. Now I want to start some
          processes in that
          > server which hosts the Queue - and not in any other server - like a
          polling program.
          > So somehow that has to detect that the Queue is local to that server
          though the
          > JNDI name is replicated in the cluster ie all members in the cluster
          should be
          > able to see the Queue.
          >
          > thanks
          > Anamitra
          

Similar Messages

  • Distributed queue usage with custom queue listeners in cluster

    Hi,
    Can someone help in solving the issue. We have a web application which will create consumers(threads in infinite loop) for an inbound queue(name comes from DB table) and after doing certain process result will be pushed to outbound queue(name comes from DB table).
    When application runs in single managed server(without clustering) every thing works fine.
    If I want to deploy the same application in two managed servers (with are under same cluster) which talks to same DB how to handle above scenario
    1. Create 2 JMS servers one on each managed server(on different machines)
    2. Create queue one for each JMS server
    3. Create distributed queue and add above two queues as members of it
    4. Create connection factory and target it to cluster
    After creating above instrastructure(similar infrastructure will be created for inbound and outbound queue), can I use distributed queue JNDI name to create listeners(threads) to read messages? Or do I need to create listeners for each individual member in the distributed queue?
    I know that while sending message to distributed queue, I can create sender on distributed queue and weblogic automatically takes care of sending the message to appropriate member in the DQ, but how it works for distributed queue?
    Also, want to know how can I access distributed queue? For example, if managed server 1 is accessed by http://10.11.134.24:7001 and managed server 2 is accessed by http://10.11.134.25:7001. which URL I need use in JNDI context provider URL to access distributed queue? can I use any URL will it make any difference?
    Generally for servlets/JSPs we create proxy server to access it through cluster, instead of directly using managed server URLs. But how it works for distributed queue?
    Thanks
    Santhosh
    Edited by: user8676720 on Oct 4, 2011 8:35 AM

              Yes.
              It turns out that if replicate local queue jndi name in cluster is set to false
              the message did not get forward :(
              Dongbo Xiao <[email protected]> wrote:
              >Sorry, the attribute is ForwardDelay, not ForwardPolicy.
              >
              >Dongbo
              >
              >Dongbo Xiao wrote:
              >
              >> Hi Eran,
              >>
              >> Have you set up the ForwardPolicy for the Distributed Queue?
              >> By default, the ForwardPolicy is -1, which turns off the forwarding.
              >>
              >> Dongbo
              >>
              >> eran wrote:
              >>
              >> > Hello,
              >> > I have 2 nodes in cluster each one has a pinned JMS server with a
              >queue QueueA
              >> > and QueueA2
              >> > respectively both mebers in a distributed destination dist_queue.
              >> > There is a consumer on QueueA only (startup class).
              >> > In case of a message sent to QueueA2 a consumer is created for QueueA2
              >automaticly
              >> > (seen in the admin console) out of the blue, and the message do not
              >get forward
              >> > to QueueA where my consumer is listening.
              >> > Monitoring JMS connections of both servers shows only my consumers'
              >connection.
              >> > Our application depends on the forward feature.
              >> > Am I doing something wrong? any ideas?
              >> >
              >> > Thanks.
              >> > Eran
              >
              

  • Issue listeneing queue from Weblogic Cluster server with multiple managed server

    Haveing issue listeneing queue from Weblogic Cluster server with multiple managed server.
    Weblogic Cluster structure is like
    Weblogic Cluster01
      --ManagedServer01(http://server01.myhost.com:7001)
      --ManagedServer02(http://server02.myhost.com:7001)
    JMS Servers
      JMSserver01 targeting: ManagedServer01
      JMSserver02 targeting: ManagedServer02
      JMSmodule
      ConnectionFactory01 targeting:JMSserver01,JMSserver02
      UDQueue01 targeting:JMSserver01,JMSserver02
    Uniform Distributed Queue in Monitoring tab showing like this
      mysystemmodule!JMSserver01@UDQueue01
      mysystemmodule!JMSserver02@UDQueue01
    So when I am sending message to any Host(by specifying the provider URL) its distributing equally on both server like
      mysystemmodule!JMSserver01@UDQueue01 10
      mysystemmodule!JMSserver02@UDQueue01 10
    But when try to listen message from these queue, it is listening from one server, for which URL given to connect.
      mysystemmodule!JMSserver01@UDQueue01 0
      mysystemmodule!JMSserver02@UDQueue01 10
    untill I connect to other server by giveing its URL, will not able to access other message left on the queue.
    Solutions that tried
      1) we have tried give both server URL coma sparated in provider URL
    we need to configur same scenario for 5 managed server with 3 listener on other servers.
    Do any one have solution for this.

    You need to have:
    1. Consumers connected to each UDQ member
    OR
    2. If no consumers in some of the members is expected, you can configure Forward Delay (specify the amount of time, in seconds, that a queue member with messages, but with no consumers, will wait before forwarding its messages to other queue members that do have consumers):
    http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13952/taskhelp/jms_modules/distributed_queues/ConfigureUDQGeneral.html
    For example you can set it to 10 (10s)
    Additional Information here:
    http://docs.oracle.com/cd/E23943_01/web.1111/e13727/dds.htm#i1314228
    http://docs.oracle.com/cd/E23943_01/apirefs.1111/e13951/mbeans/DistributedQueueBean.html?skipReload=true#ForwardDelay
    How Does JMS Load Balancing Work with Distributed Queues and Uniform Distributed Queues? (Doc ID 827294.1)
    I hope this helps
    Best Regards
    Luz

  • The local node entry in Cluster Configuration information does not match wi

    In installing 10.1.0.3 CRS on Solaris 8 x86, I keep getting the error, "The local node entry in Cluster Configuration information does not match with the entry in /etc file." Both addresses are defined in the /etc/inet/hosts and are pingable. There seems to be no way to get past this issue. Earlier I installed 10.2.0.1 CRS on SLES9 SP2 on a system with the same network settings and had no problem. Is there some way to force the installer to accept the addresses given and proceed past this step?

    All,
    I think there can be two problems
    1.
    if your host file looks as follows
    # Public
    192.168.2.x rac1.localdomain rac1
    192.168.2.x rac2.localdomain rac2
    #Private
    192.168.0.x rac1-priv.localdomain rac1-priv
    192.168.0.x rac2-priv.localdomain rac2-priv
    #Virtual
    192.168.2.x rac1-vip.localdomain rac1-vip
    192.168.2.x rac2-vip.localdomain rac2-vip
    then you should be able to do rsh or ssh sucessfully for each aliases at least one from each nodes
    (ex)
    on node rac1
    ssh rac1 date
    ssh rac1.localdomain date
    ssh rac2 date
    ssh rac2.localdomain date
    2. you should create user equivalance on all the nodes as follows
    Edit the /etc/hosts.equiv file to include all the RAC nodes:
    +rac1 oracle
    +rac2 oracle
    +rac1-priv oracle
    +rac2-priv oracle                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • XA required when operating on 2 local queues?

    Hi,
    I have got 2 local queues. The application is clustered. I have got a MDB reading from a queue, and posting a message in the 2nd queue. Both queues are hosted by the same JMS Provider. Reading and posting are 2 actions done in the same transaction.
    Do I need to use a XA connection factory in that situation?
    thanks,
    vs

    vs, to my knowledge the answer is yes. It's a very easy option to configure in the Admin Console. You can read about some of the jms transaction options here: http://edocs.bea.com/wls/docs100/jms/trans.html

  • Always selecting the local JMS in a cluster, is it possible? (in 6.1)

    Hi,
              A 6.1 cluster has a JMS server running on each node. The JMS client
              code has a component to do the fail over "manually": it tries one
              node, if that doesn't work it tries the next and so on. The
              destination names are different (and replicated in the JNDI tree).
              If everything is ok, all requests go the first server (meaning network
              traffic). Is there an elegant way to always try with the local JMS
              server before the remote ones, without minimum configuration
              dependency (i.e. no system properties passed at start-up telling what
              JMS servers to use and so on)
              Perhaps something using JMSDestinationRuntimeMBean and
              JMSServerRuntimeMBean?
              Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              it. I'll post it nonetheless in case other people have better ideas.
              Thanks.
              

    Thanks again.
              In fact, if I use the server/queue syntax, I can use the queue name
              (the Name attrribute) not the JNDI name. This in case these names can
              be the same in a cluster deployment (with replicated JNDI names
              different). I'll check soon.
              Regarding the connection factory, I wonder whether WL doesn't do its
              otherwise typical performance improvements and return a local
              connection if there is one (as it already does with remote
              interfaces). I couldn't find a reference to such an optimization in
              the JMS documentation, though.
              On Wed, 17 Apr 2002 09:37:59 -0400, Tom Barnes
              <[email protected]> wrote:
              >email wrote:
              >
              >> Thank you. The second option looks better than the first because it
              >> allows using destinations on other JMS servers (by interrogating an
              >> MBean to get the JMS servers in the cluster).
              >
              >The second option only works if the connection is already connected
              >to the correct server. If you use mbeans, you can glean the URL
              >of the correct server by obtaining the IP and address of the remote
              >server from the ServerMBean - the "target" of the JMSServerMBean.
              >
              >An issue with this feature is the connection factory - which round-robins the
              >location of connection in certain cases. Currently the only way to ensure the
              >connection
              >factory does not do this is to target it at a single server. I suppose one
              >could duplicate the connection factory and target each duplicate at
              >a different server, but that requires giving each one a different name.
              >This may not be an issue with server-side contexts, I will investigate.
              >
              >
              >> It's useful to know
              >> about JNDINameReplicated, but that way accessing a remote destination
              >> will not be possible at all.
              >>
              >
              >I think you could write a small a startup class to look up the queue in the
              >local context and register the queue in a
              >replicated context with a different JNDI name. This way the destination
              >is advertised both ways. Fairly sure this would work.
              >
              >>
              >> BTW, a related question on reliability: accessing a remote destination
              >> if the local is down means there is a local problem with the JMS
              >> server or the queue, but the container is fine. Now, how likely is
              >> this in practice? Having the container up but the JMS subsystem down.
              >>
              >
              >Parts (or all) of JMS can fail due to configuration
              >errors -- commonly JNDI name collisions of destinations and/or factories,
              >failure to set the target, or using the same server name or jms server name
              >on two different servers.
              >
              >If you are using a file-store, boot failures occur with things
              >like file-store not found, or relatively catastrophic failures like
              >out-of-memory.
              >
              >If you are using a JDBC store, there is a dependency on the database being up.
              >
              >
              >>
              >> Indeed, 7.0 would solve it but that's several months ahead if I
              >> understand correctly:)
              >>
              >
              >Not months. Weeks. A very few weeks. I'm not sure what is officially
              >announced
              >so I can't get more specific.
              >
              >>
              >> Thanks again.
              >>
              >> On Tue, 16 Apr 2002 14:48:02 -0400, Tom Barnes
              >> <[email protected]> wrote:
              >>
              >> >Consider the new "JNDINameReplicated" configuration parm on the
              >> >destination. Ensure each server running 6.0SP2 with patch CR061106, or
              >> >6.1SP3 (not out yet) and later, or 7.0. Configure each queue to have the
              >> >same JNDI name, and also take care to set the destination’s new
              >> >“JNDINameReplicated” parameter to false. This turns off name
              >> >replications, so the JNDI name of the dest is only visible on the server
              >> >local to the context.
              >> >
              >> >Consider naming all destinations the same and looking them up the dest via
              >> >session.createQueue("./queuename"), this is a new syntax that restricts
              >> >the lookup to the same server as the one the JMS connection is talking
              >> >to. The normal syntax is "servername/queuename". This feature is
              >> >slated for 6.1SP3, no guarantees, (or try ask customer support to get this
              >> >feature in early as a patch, no guarantees there either), or 7.0.
              >> >
              >> >Consider not rolling your own and using 7.0, which has a rich distributed
              >> >destination feature built in.
              >> >
              >> >Tom
              >> >
              >> >email wrote:
              >> >
              >> >> Hi,
              >> >>
              >> >> A 6.1 cluster has a JMS server running on each node. The JMS client
              >> >> code has a component to do the fail over "manually": it tries one
              >> >> node, if that doesn't work it tries the next and so on. The
              >> >> destination names are different (and replicated in the JNDI tree).
              >> >>
              >> >> If everything is ok, all requests go the first server (meaning network
              >> >> traffic). Is there an elegant way to always try with the local JMS
              >> >> server before the remote ones, without minimum configuration
              >> >> dependency (i.e. no system properties passed at start-up telling what
              >> >> JMS servers to use and so on)
              >> >>
              >> >> Perhaps something using JMSDestinationRuntimeMBean and
              >> >> JMSServerRuntimeMBean?
              >> >>
              >> >> Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              >> >> it. I'll post it nonetheless in case other people have better ideas.
              >> >>
              >> >> Thanks.
              >> >
              >
              

  • Local Beans in a Cluster

    Is it possible to use EJB2.0 Local Interface EJBs in a cluster?
    If so, what happens when clients on two different servers attempt to access the
    same entity bean?

    Even when not using Local Interfaces, Weblogic (by default) will prefer to
    use a co-located bean rather than make an inter-JVM call. Depending on your
    EJB concurrency strategy, you can have a number of bean instances for the
    same EJB data - and the database handles the concurrency. It is usually
    cheaper to instantiate a local instance of the bean than make and inter-JVM
    call (this is especially so when it comes to coordinating transactions and
    the extra network traffic negotiating a 2PC commit). This is the default
    concurrency strategy and the default cluster behaviour for WLS as of 6.0.
    So, the short answer is that it will use a local instantiation of the entity
    bean - and the database will handle the concurrency.
    -Nick
    "David Roytenberg" <[email protected]> wrote in message
    news:[email protected]..
    >
    Is it possible to use EJB2.0 Local Interface EJBs in a cluster?
    If so, what happens when clients on two different servers attempt toaccess the
    same entity bean?

  • Queue visibility in cluster

              Hi
              If I create a JMS server and a destination and then attach it to a member of the
              cluster - will every other member be able to see that destination? I am finding
              that this is not happening in wls 7.0 sp2 clustering. I just have 2 managed servers
              and have attached the Queue to one of them - but the Queue is not getting visible
              from the other servers JNDI tree. Am I doing something wrong or this is a bug
              - pls dont say this is how it works - that would be really bad.
              thanks
              Anamitra
              

    Hi Anamitra,
              I know the customer is always right! ;-)
              But you are trying something that is very common, we have
              many customers using JMS in clusters, and we DO actually test -
              thousands of JMS tests that variously run per-build, nightly,
              and per SP.
              So please forgive me if my first instinct is that
              there is not a WebLogic problem here, but instead a "first-time"
              setup problem. I fully admit that there is a chance you are
              right, but lets look at the other possibilities first.
              Please refer to my upcoming response in your other
              recent thread for continued discussion.
              Tom
              Anamitra wrote:
              > Hi
              > I am pretty confident that I have done the cluster setup right. for example I
              > create a QueueConnectionFactory and target it to the cluster - the JNDI tree of
              > both the servers shows that object. All the debug statements when the servers
              > start up show that they are able to see each other and they are in the same cluster
              > same domain. Its on ly in case of jms servers - which I have to pin to one server
              > [say server1] I dont see it in the otther serverrs jndi tree. This seems like
              > a bug and it used to work perfectly in other the 7.0 b version without the service
              > pack.
              > Let me get it clear once again - Even if the queue is attached to a server in
              > the cluster - all the other servers jndi tree should show the Queue object - right?
              > In this case it is not doing so - so this seems like a bug - but a very blatant
              > one which makes me really nervous - this kind of bug cannot get pass the QA -
              > But I am kind of sure that I am doing it right - All other objects become visible
              > [though they are all deployed targetted to the cluster and not a single server]
              > Even the MDB jar files that I deploy gets distributed properly to all the other
              > servers. Do you have any suggestion for me?
              >
              > thanks
              > Anamitra
              >
              >
              >
              > Dongbo Xiao <[email protected]> wrote:
              >
              >>Hi Anamitra,
              >>
              >>A destination that is targeted to a member of a cluster will be visible
              >>to
              >>all other members of the cluster unless you explicitly set JNDINameReplicated
              >>attribute of the destination to "false" (its value is "true" by default).
              >>The only suggestion I have for you is to check your configuration and
              >>see if
              >>both of the managed servers are in the same cluster and the destination's
              >>JNDINameReplicated attribute is set right.
              >>Have you tried this in other WLS releases?
              >>
              >>Thanks,
              >>Dongbo
              >>
              >>
              >>Anamitra wrote:
              >>
              >>
              >>>Hi
              >>>If I create a JMS server and a destination and then attach it to a
              >>
              >>member of the
              >>
              >>>cluster - will every other member be able to see that destination?
              >>
              >>I am finding
              >>
              >>>that this is not happening in wls 7.0 sp2 clustering. I just have 2
              >>
              >>managed servers
              >>
              >>>and have attached the Queue to one of them - but the Queue is not getting
              >>
              >>visible
              >>
              >>>from the other servers JNDI tree. Am I doing something wrong or this
              >>
              >>is a bug
              >>
              >>>- pls dont say this is how it works - that would be really bad.
              >>>
              >>>thanks
              >>>Anamitra
              >>
              >
              

  • MDB linked to a queue of different cluster ?

              Hi,
              Is it possible to deploy an MDB in cluster-1 and in deployment descriptor specify
              a queue belonging to a different cluster say cluster-2. I want to avoid bridge.
              thanks
              saurabh
              

              I found that it can be done by specifying provider-url in deployment descriptor.
              thanks
              - saurabh
              "Saurabh Kumar" <[email protected]> wrote:
              >
              >Hi,
              >
              >Is it possible to deploy an MDB in cluster-1 and in deployment descriptor
              >specify
              >a queue belonging to a different cluster say cluster-2. I want to avoid
              >bridge.
              >
              >thanks
              >saurabh
              

  • JMS stand-alone client consuming a queue in GlassFish cluster

    I want to connect to a JMS queue running in clustered glassfish enterprise 2.1 and consume a message. I have a simple client app. that works with my one-machine cluster (pointing it either to first or second node, ports 3330 or 3331), but doesn't work with a company cluster (two machines, two nodes).
            Hashtable properties = new Hashtable();
            properties.put(Context.PROVIDER_URL, "iiop://" + hostname + ":" + port);
            properties.put("org.omg.CORBA.ORBInitialHost", hostname);
            properties.put("org.omg.CORBA.ORBInitialPort", "" + port);
            properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.appserv.naming.S1ASCtxFactory");
            try {
                ctx = new InitialContext(properties);
            } catch (NamingException ex) {
                ex.printStackTrace();
            }The program fails on line ctx = new InitialContext(properties);
    The strange thing is, whatever I use as hostname or port, it always ends like this:
    27.5.2009 18:03:17 com.sun.appserv.naming.RoundRobinPolicy setClusterInstanceInfo
    WARNING: NAM1005 : No Endpoints selected. Please specify using system property com.sun.appserv.iiop.endpoints.
    27.5.2009 18:03:17 com.sun.appserv.naming.RoundRobinPolicy getEndpointForProviderURL
    WARNING: NAM1001: No Endpoints selected in com.sun.appserv.iiop.endpoints property. Using JNDI Provider URL iiop://10.0.0.30:33700 instead
    27.5.2009 18:03:18 com.sun.appserv.naming.RoundRobinPolicy setClusterInstanceInfo
    INFO: endpoint.weight after checking isWeight = 10
    27.5.2009 18:03:18 com.sun.appserv.naming.RoundRobinPolicy setClusterInstanceInfo
    INFO: sumOfAllWeights = 10
    27.5.2009 18:03:19 com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
    WARNING: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
    org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No
            at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2690)
            at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2711)
            at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:261)
            at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
            at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:130)
            at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:192)
            at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:181)
            at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:325)
            at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
            at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
            at com.sun.corba.ee.impl.folb.ClientGroupManager.getInitialClusterInstanceInfo(ClientGroupManager.java:596)
            at com.sun.corba.ee.impl.folb.ClientGroupManager$GIS.getClusterInstanceInfo(ClientGroupManager.java:620)
            at com.sun.corba.ee.impl.folb.ClientGroupManager.getClusterInstanceInfo(ClientGroupManager.java:666)
            at com.sun.appserv.naming.GroupInfoServiceObserverImpl.membershipChange(GroupInfoServiceObserverImpl.java:73)
            at com.sun.appserv.naming.S1ASCtxFactory.getInitialContext(S1ASCtxFactory.java:290)
            at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
            at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
            at javax.naming.InitialContext.init(InitialContext.java:223)
            at javax.naming.InitialContext.<init>(InitialContext.java:197)
            at client.JmsQueueConsumer.<init>(JmsQueueConsumer.java:41)
            at client.JmsQueueConsumer.main(JmsQueueConsumer.java:57)
    Caused by: java.lang.RuntimeException: java.net.ConnectException: Connection refused: connect
            at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:347)
            at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:244)
            ... 18 more
    Caused by: java.net.ConnectException: Connection refused: connect
            at sun.nio.ch.Net.connect(Native Method)
            at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
            at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
            at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)
            ... 19 moreI've tried to turn off all firewalls between me and the cluster but it still doesn't work. ANy ideas what can be wrong? I guess clusters are always different...
    (I will try to do more investigation, especially packet capturing, later)

    Double check the ORB configuration in the servers...
    +"The default naming service port in the app server is 3700. If the naming service is running on a different port, you'll need to set it via the -Dorg.omg.CORBA.ORBInitialPort property when starting the client JVM. You can double-check the actual naming service port for a given server instance by looking in the server instace's domain.xml for "orb-listener-1". Alternatively, check the Applications..Configuration..ORB..IIOP Listeners section of the admin GUI for orb-listener-1."+
    [https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB|https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB] (step-5)
    Edited by: Conchas on Aug 3, 2009 12:12 PM

  • Accessing Distributed Queue In a Cluster via the Proxy Server

              I am running WL 8.1 SP2. I have a configuration where I have 3 servers (on two
              different machines) running in a cluster. I have a separate server on a 3rd machine
              running the cluster proxy server for a single point of access to the cluster.
              I have configured a distributed queue and a distributed topic, each targeted
              to all servers in the cluster.
              Now I have a JMS client which is a separate java application that is trying to
              connect to the distributed queue and topic in the cluster. If the client connects
              directly to one of the cluster machines, it is able to successfully interact with
              the JMS queue and topic. But if it attempts to connect via the proxy server it
              gets an error saying the queue and topic does not exist.
              So what am I missing? Do I need to configure a separate JMS server on the proxy
              server and add that as part of the distributed queue & topic (this didn't seem
              to allow me to add anything outside of the cluster). Is there any special configuration
              in the proxy to pass through JMS requests? I'm currently using a WL logic server
              as my front-end proxy server but does anything change if I want to use Apache
              with the WL Proxy plug-in??
              Jerald
              

              "Jerald Pratt" <[email protected]> wrote in message
              news:[email protected]...
              >
              > I am running WL 8.1 SP2. I have a configuration where I have 3 servers
              (on two
              > different machines) running in a cluster. I have a separate server on a
              3rd machine
              > running the cluster proxy server for a single point of access to the
              cluster.
              > I have configured a distributed queue and a distributed topic, each
              targeted
              > to all servers in the cluster.
              >
              > Now I have a JMS client which is a separate java application that is
              trying to
              > connect to the distributed queue and topic in the cluster. If the client
              connects
              > directly to one of the cluster machines, it is able to successfully
              interact with
              > the JMS queue and topic. But if it attempts to connect via the proxy
              server it
              > gets an error saying the queue and topic does not exist.
              Yup... That makes sense...
              >
              > So what am I missing? Do I need to configure a separate JMS server on the
              proxy
              > server and add that as part of the distributed queue & topic (this didn't
              seem
              > to allow me to add anything outside of the cluster). Is there any special
              configuration
              > in the proxy to pass through JMS requests? I'm currently using a WL logic
              server
              > as my front-end proxy server but does anything change if I want to use
              Apache
              > with the WL Proxy plug-in??
              One option I have used frequenly is specifying java.naming.provider.url as
              cluster address (e.g. t3://server1:7001,server2:7001
              You may also want to look into tunnelling...
              >
              > Jerald
              >
              

  • Reading messages from all distributed queues on a cluster (WLS 9.2)

    Hi,
    I have a following problem with distributed queues on WebLogic Server 9.2 MP1.
    Here's a brief description of my setup:
    I've got a cluster called 'myCluster', and two cluster nodes on it, 'nodeA' and 'nodeB'. I also have two JMS servers, 'jmsA' and 'jmsB'. Then I have a jms module 'myModule' with a subdeployment 'mySubdeployment' targeted on jms servers 'jmsA' and 'jmsB'. I have a jms connection factory 'TestFactory' that is targeted on myCluster (default targetting), and a jms queue 'TestQueue' (Uniform Distributed Queue) using subdeployment 'mySubdeployment' (targeted to 'jmsA' and 'jmsB').
    Now, the queue 'TestQueue' is used as a location where messages are stored when the system has met a problem in the environment that is preventing the normal handling of messages. Messages are kept in this queue until the problem is over, that's when the system administrator uses a browser application that requests the system to read the messages and handle them normally.
    The problem is that the cluster node which gets the request seems to be able to read only its own queue and the messages on the other nodes queue are left untouched. I know that I could send a message to the another node for example via topic 'purge_your_messages', but that's not suitable for this case. I need to sort the messages by their ids (set as a message property) and because of that I need exactly one node executing the purge.
    Any advice?
    - jj
    Edited by: user5736915 on 10-Dec-2008 14:10

    Browsers and receivers always attach to a single member of a distributed destination.
    WebLogic MDBs, on the other hand, automatically handle the task of attaching receivers to every member, and are quite simple to code and use these days. If you have the option of using WL MDBs, I recommend using them. (There's no equivalent for browsers.)
    Spring won't do the same OOTB, but there does appear to be a work-around for the Spring receiver issue (albeit not for browsers - just receivers). Here's a sample Spring impl that attaches a subscription to each and every member of a distributed topic:
    http://sleeplessinslc.blogspot.com/2011/12/weblogic-jms-partitioned-distributed.html.
    If the above isn't helpful, and you must cycle through every message on every server in the cluster, then you'll need write special case code to check each separately. There are two common options for enumerating the destinations and working with each one - the JMX mbean "message management" APIs (WLST Jython scripting or Java based) and the weblogic.jms.extensions destination availability APIs.
    HTH,
    Tom

  • Local NFS / LDAP on cluster nodes

    Hi,
    I have a 2-node cluster (3.2 1/09) on Solaris 10 U8, providing NFS (/home) and LDAP for clients. I would like to configure LDAP and NFS clients on each cluster node, so they share user information with the rest of the machines.
    I assume the right way to do this is to configure the cluster nodes the same as other clients, using the HA Logical Hostnames for the LDAP and NFS server; this way, there's always a working LDAP and NFS server for each node. However, what happens if both nodes reboot at once (for example, power failure)? As the first node boots, there is no working LDAP or NFS server, because it hasn't been started yet. Will this cause the boot to fail and require manual intervention, or will the cluster boot without NFS and LDAP clients enabled, allowing me to fix it later?

    Thanks. In that case, is it safe to configure the NFS-exported filesystem as a global mount, and symlink e.g. "/home" -> "/global/home", so home directories are accessible via the normal path on both nodes? (I understand global filesystems have worse performance, but this would just be for administrators logging in with their LDAP accounts.)
    For LDAP, my concern is that if svc:/network/ldap/client:default fails during startup (because no LDAP server is running yet), it might prevent the cluster services from starting, even though all names required by cluster are available from /etc.

  • Local Director 417 in cluster situation

    Hi,
    I have a LD 417 to forward packets to 2 servers (A&B running redhat cluster suite). The IP address of server A and B are 10.10.10.1 and 10.10.10.2 respectively. The virtual ip for server A and B is 10.10.10.3.
    Since the 2 servers are clusters, only 1 server will be running a service at a time. The service runs at port 5000.
    My questions:
    1. LD 417 will need to route packets to the server which is running the service. How does LD 417 determines that the service is running at server A instead of B ? Is there any command such as keepalive ? what mechanism does LD 417 use ?
    2. If I set the bind as follow:
    bind 10.10.10.3:5000:0:tcp 10.10.10.3:5000:0:tcp
    How can I divert all other packets going to vip 10.10.10.3 to another server (10.10.10.11) ?
    Thanks for the help ?

    the LD uses inband health monitoring.
    It forwards client traffic to server and if the LD does not see a response from the server, it consider it as dead [there are thresholds associated with this].
    localdirector(config)# threshold ?
    usage: threshold
    There is also probes that can be generated but it is limited to dns and http.
    localdirector(config)# pro?
    probe
    probeconfig
    probedns
    probehttp
    If you want to redirect other traffic to another address, you first need to create a vserver to catch this traffic, a real server to receive the traffic an d then bind the 2 togethers.
    Gilles.

  • MDB in a Cluster using Local JMS Queue (not distributed)

              Can I create a MDB that receives messages from a Local JMS Queue (created on each
              node) rather than a distributed queue?
              When I try to deploy such an MDB I get the following exception:
              weblogic.management.DeploymentException: Exception:weblogic.management.ApplicationException:
              activate failed for TestLocalMDBCluster Module: TestLocalMDBCluster Error: Exception
              activating module: EJBModule(TestLocalMDBCluster,status=PREPARED) Unable to deploy
              EJB: AsyncProcessor from TestLocalMDBCluster.jar: [EJB:011046]Unable to create
              EJBRuntimeMBean. javax.management.InstanceAlreadyExistsException: mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,Location=Node2,Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,ServerRuntime=Node2,Type=MessageDrivenEJBRuntime
              at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134)
              at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2371)
              at com.sun.management.jmx.MBeanServerImpl.registerMBean(MBeanServerImpl.java:876)
              at weblogic.management.internal.RemoteMBeanServerImpl.private_registerMBean(RemoteMBeanServerImpl.java:582)
              at weblogic.management.internal.RemoteMBeanServerImpl.registerMBean(RemoteMBeanServerImpl.java:524)
              at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:166)
              at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:122)
              at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:85)
              at weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.<init>(EJBRuntimeMBeanImpl.java:33)
              at weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:30)
              at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.initPool(MessageDrivenBeanPoolInfoImpl.java:182)
              at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.activate(MessageDrivenBeanPoolInfoImpl.java:245)
              at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.activatePoolInfo(MessageDrivenBeanInfoImpl.java:474)
              at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:440)
              at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1327) at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:610)
              at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3127)
              at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2081)
              at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2062)
              at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2592)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2515)
              at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2317)
              at weblogic.management.deploy.slave.SlaveDeployer.commitUpdate(SlaveDeployer.java:608)
              at weblogic.drs.internal.SlaveCallbackHandler$2.execute(SlaveCallbackHandler.java:35)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              Is there any way to do this?
              

    I assume you are using queues.
              I truly wonder what you are doing different. Since the
              error is occuring outside of JMS and in the EJB - before JMS is called -
              I suggest posting to the ejb newsgroup.
              Note that yours is a standard use case which distributed destinations
              are actually specifically designed for (if you
              are using customer connection factories, just
              make sure ServerAffinity is enabled on the connection factory to
              ensure that clients always connect to the local physical destination,
              configure the MDB to refer to the JNDI name of the distributed
              destination, and then target the MDB to the cluster - an MDB pool
              will then automatically be dedicated to each physical destination).
              Tom
              Mark Colwell wrote:
              > Nope. It happens every time we try the scenario no matter what the application
              > is or which cluster. It always happens if we try to deploy even just a single
              > MDB (no other beans in the jar) to a cluster where the queue specified in the
              > deployment descripter is a local queue created on each node in the cluster. When
              > the jar is deployed we get the error.
              >
              > We have a strange situation were we really need the queue to be local and not
              > distributed but existing on every node. We can create all the local queues no
              > problem but trying to then deploy the application goes boom.
              >
              > Thanks for the response!
              >
              > Cheers,
              > Mark
              >
              > Tom Barnes <[email protected].bea.com>
              > wrote:
              >
              >>Mark Colwell wrote:
              >>
              >>
              >>>Can I create a MDB that receives messages from a Local JMS Queue (created
              >>
              >>on each
              >>
              >>>node) rather than a distributed queue?
              >>
              >>Yes. In fact this is the most common use case.
              >>
              >>
              >>>When I try to deploy such an MDB I get the following exception:
              >>
              >>I don't recall seeing this exception before. It looks like a naming
              >>conflict - it appears that somehow something is already running with
              >>the same name. Are you somehow deploying the same app twice?
              >>
              >>javax.management.InstanceAlreadyExistsException:
              >>mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,
              >>EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,
              >>Location=Node2,
              >>Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,
              >>ServerRuntime=Node2,
              >>Type=MessageDrivenEJBRuntime
              >>
              >>FYI: As of one or two weeks ago, the MDB section of the
              >>EJB docs has been heavily updated. I highly recommend
              >>reading it.
              >>
              >>
              >>>weblogic.management.DeploymentException: Exception:weblogic.management.ApplicationException:
              >>>activate failed for TestLocalMDBCluster Module: TestLocalMDBCluster
              >>
              >>Error: Exception
              >>
              >>>activating module: EJBModule(TestLocalMDBCluster,status=PREPARED) Unable
              >>
              >>to deploy
              >>
              >>>EJB: AsyncProcessor from TestLocalMDBCluster.jar: [EJB:011046]Unable
              >>
              >>to create
              >>
              >>>EJBRuntimeMBean. javax.management.InstanceAlreadyExistsException: mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,Location=Node2,Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,ServerRuntime=Node2,Type=MessageDrivenEJBRuntime
              >>>at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134)
              >>>at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2371)
              >>>at com.sun.management.jmx.MBeanServerImpl.registerMBean(MBeanServerImpl.java:876)
              >>>at weblogic.management.internal.RemoteMBeanServerImpl.private_registerMBean(RemoteMBeanServerImpl.java:582)
              >>>at weblogic.management.internal.RemoteMBeanServerImpl.registerMBean(RemoteMBeanServerImpl.java:524)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:166)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:122)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:85)
              >>>at weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.<init>(EJBRuntimeMBeanImpl.java:33)
              >>>at weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:30)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.initPool(MessageDrivenBeanPoolInfoImpl.java:182)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.activate(MessageDrivenBeanPoolInfoImpl.java:245)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.activatePoolInfo(MessageDrivenBeanInfoImpl.java:474)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:440)
              >>>at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1327)
              >>
              >>at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:610)
              >>
              >>>at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3127)
              >>>at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2081)
              >>>at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2062)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2592)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2515)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2317)
              >>>at weblogic.management.deploy.slave.SlaveDeployer.commitUpdate(SlaveDeployer.java:608)
              >>>at weblogic.drs.internal.SlaveCallbackHandler$2.execute(SlaveCallbackHandler.java:35)
              >>>at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at
              >>
              >>weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              >>
              >>>Is there any way to do this?
              >>
              >
              

Maybe you are looking for