JMS server targeted to several clusters

Hello,
I am facing a problem with my JMS configuration in weblogic (version 10.3.4.0). I have two clusters. Following the [JMS best practice|http://forums.oracle.com/forums/message.jspa?messageID=9455261#9455261] I have created a JMS server in each Managed server within the clusters. I have created only one JMS Module with a subdeployment. The JMS Module is targeted to all managed servers within both clusters, and the subdeployment is targeted to all JMS servers within the clusters.
At the JMS module I have created a connection Factory targeted to the subdeployment, till there everything is ok.
Afterwards I try to create a uniform distributed queue (UDQ) targeted to the subdeployment and WebLogic throws the following error:
A UDD must be targeted to servers within a single cluster or a single stand-alone server, rather than Cluster ClusterA and Cluster ClusterB
The only solution that I found is to create one JMS Module-subdeployment per JMS Server. Is there a way to have just a JMS Module and use it in all the managed server in several clusters? or I have to set up the same parameters (ConnectionFactories + queue +quota) in each JMS Module.
Thank you very much in advance.
Cheers,
Oscar

Hi Oscar,
The correct way to step-up a UDQ is something like below
C-1 => MS-1 + MS-2
JMSServer-1 => MS-1
JMSServer-2 => MS-2
JMSModule-1 => C-1
Sub_UDQ => JMSServer-1 + JMSServer-2
UDQ => Sub_UDQ
CF => C-1
Where:
======
MS-x are the managed servers
C-x are the Cluster
UDQ is the Uniform Distributed Queue
Sub_UDQ is the Sub-Deployment for UDQ
CF is the Connection Factory
*=>* mean Targeted.
Also to get more information on it you can have a look at the below link which has the step by step instructions which would surely help you out
Topic: Steps to Configure Uniform Distributed Queue (UDQ) on Weblogic Server
http://middlewaremagic.com/weblogic/?p=3747
Regards,
Ravish Mody

Similar Messages

JMS Server targeted to Server cluster

Hi , Can JMS Server be targeted to Server Cluster? Are there any
          architectural best practices for this?

Thanks Tom.
          <Tom Barnes> wrote in message news:[email protected]...
          There's no underlying machinery (code) that supports targeting a JMS server
          to a cluster.
          The targeting problem can actually get fairly involved - for a variety of
          reasons, I tend to recommend the following cookie cutter approach.
          This is a cut-and-paste from my notes:
          (1) Create a custom WL store on each server, and target it to a migratable
          target (most of the time you can use the default migratable target that each
          server provides).
          (2) Target the JMS servers to a migratable target each, the same MT as the
          store (don't worry, the JMS server won't wander to a different server
          unless you configure the MT to allow this!)
          (3) Target jms configuration system modules to the cluster (that's it! - not
          to anything else)
          (4) Create one subdeployment per module (and only one), populate the
          subdeployment only with JMS servers from step (2) above.
          (5) When targeting destinations always use advanced targeting to target
          destinations to the subdeployment from above - not the 'default target'.
          If you have both non-distributed and distributed destinations, use two
          different JMS modules. (The idea is to keep things simple to understand -
          each module should yield the same targeting solution for all of its
          component resources. Default targetting can be problematic - it is far too
          easy for destination members to end up on JMS servers that you don't want
          them on.).
          (6) When targeting a CF you have two options (A) use advanced targeting to
          target it to the subdeployment (for access by applications that are remote
          to the cluster) or (B) don't target it all (this will cause it to use the
          module target, which if you recall, we just set to the cluster, (for access
          by applications that run on a server within the cluster). The choice
          actually depends on how you plan to use the CF - use (B) for apps running on
          servers within the cluster, and (A) for apps running remote to the cluster.
          See the otherwise-largely-outdated JMS Performance Guide for the reasoning.
          It may be that you don't have to use migratable targets, as you may not have
          a use for "migration" at the moment - but it'll help in the future if you
          ever plan to use the migration features.
          Tom

JMS Server Target & Deploy error

          Hi All,
          I am getting the error while creating the JMS Server.
          I have created the JMS Server and on Target and Deploy tab,when I select the server
          name as target and hit the Apply button, I get the following error
          An unexpected error occurred while setting Target to mydomain:Name=myserver(migratable),Type=MigratableTarget.
          what could be the reason?
          Thanks
          WD


It still seems like it is your app that is throwing the exception.
          If you post the full log message, not just the excerpted text,
          the problem might be self evident.
          WD wrote:
          > The applications code is fine. With the same ear file,I am getting this error
          > intermittently. My suspicions is that sometimes when I redeploy the same application(without
          > anything changed), wls does not deploy it properly. Because when I was getting
          > this error,I just undeployed and deployed the app and it worked.
          > Have you seen this kind of behavior with wls?
          >
          > Thanks
          > WD
          >
          >
          >
          > Tom Barnes <[email protected].bea.com>
          > wrote:
          >
          >>It is unusual not to have a full stack trace - particularly
          >>for application generated exceptions. My first
          >>suspicions is that your app is creating a producer
          >>without specifying a destination (a non-pinned producer),
          >>and then attempting to send a message without specifying
          >>a destination.
          >>
          >>WD wrote:
          >>
          >>>The only log message I have is the one I posted earlier. It is from
          >>
          >>the log file.
          >>
          >>>
          >>>
          >>>Tom Barnes <[email protected].bea.com>
          >>>wrote:
          >>>
          >>>
          >>>>OK. For this new exception, do you have the full
          >>>>log message/stack trace?
          >>>>
          >>>>WD wrote:
          >>>>
          >>>>
          >>>>
          >>>>>I just left the app alone for the weekend and when I tried to do it
          >>>>
          >>>>again today,it
          >>>>
          >>>>
          >>>>>just worked. I do not know what was wrong with it on friday.
          >>>>>
          >>>>>But now I am running into another weird error. I have deployed my
          >>
          >>application
          >>
          >>>>>and it works fine and MyMDB also works fine. But sometimes I am getting
          >>>>
          >>>>the following
          >>>>
          >>>>
          >>>>>error. It is happening very intermittently.
          >>>>>
          >>>>>Exception in MyMDB.onMessage()Must provide destination
          >>>>>
          >>>>>Thanks
          >>>>>WD
          >>>>>
          >>>>>
          >>>>>Tom Barnes <[email protected].bea.com>
          >>>>>wrote:
          >>>>>
          >>>>>
          >>>>>
          >>>>>>Do you have the full log message/stack trace?
          >>>>>>
          >>>>>>WD wrote:
          >>>>>>
          >>>>>>
          >>>>>>
          >>>>>>
          >>>>>>>Hi All,
          >>>>>>>I am getting the error while creating the JMS Server.
          >>>>>>>I have created the JMS Server and on Target and Deploy tab,when
          >>
          >>I
          >>
          >>>>select
          >>>>
          >>>>
          >>>>>>the server
          >>>>>>
          >>>>>>
          >>>>>>
          >>>>>>>name as target and hit the Apply button, I get the following error
          >>>>>>>
          >>>>>>>An unexpected error occurred while setting Target to mydomain:Name=myserver(migratable),Type=MigratableTarget.
          >>>>>>>
          >>>>>>>what could be the reason?
          >>>>>>>
          >>>>>>>Thanks
          >>>>>>>WD
          >>>>>>>
          >>>>>>>
          >>>>>>
          >

Offline WLST changes JMS Server Target From a Migratable target

I have a simple WL 9.2mp2 domain which has 2 managed servers, one JMS Server and two migratable targets (one for each managed server) and the JMS server is targeted to one of the migratable targets. When I read the domain into WLST offline, the JMS server's target is changed from the migratable target to the preferred server defined in the migratable target. Is this a bug in WLST? Am I missing some option on WLST that can fix this?
          I saw a similar posting for 8.1 and no resolution.
          Thanks in advance,
          Mark.

Hi
          Please find my answers below:
          Q1:
          It depends how you configured the JMSSevers.
          If both the JMSServers are targeted to the same MigratableTarget, then you do the migration only once, that will move both of them to the new active server.
          If not, you have to perform the migration once for each MT.
          Q2:
          No, you dont have to start the Managed Server II, unless otherwise you wanted it to be readily available for the migration next time.
          Q3:
          You can just repeat the migration process by specifying the destination as Maganged Server-I this time. You dont need change the configuration for this, since the MT, shall already have the Candidate servers M1 and M2 and both JMSServers are targeted to MT.
          Q4:
          Yes, as long as the CF is targeted to the cluster, your connection is valid. But your destinations references will become invalid after migration, so you have to have some logic in the exception listeners to reconnect again.
          Hope this helps.

JMS Server JNDI not being replicated? (clustered environment)

Hello,
First of all, my envinronment is Weblogic 6.1 sp2, JDK 1.3.1, Windows
My current production and test environments consist, each one of them, of
clusters with one admin server (ProdAdmin) and two managed servers (Prod1
and Prod2). One of the managed servers (Prod1) is the server to which the
JMS server is deployed and everything works fine.
Now I'm trying to add another managed server to the cluster. The idea is to
target the JMS Server (and nothing else) to this node. We don't want the JMS
server to be running in Prod1 and the new server, named ProdJMS, won't even
have any deployed beans or the startup class targeted to it. Just the JMS
server. Here our problems start.
I'm able to start this ProdJMS node with no problems. However, when I start
Prod1 it seems that the JMS server is not binded. This is the exception
we're getting when a message-driven bean is being deployed (I get the same
exception trying to create other):
------- snip -------------
<May 21, 2002 12:11:42 PM EDT> <Warning> <EJB> <The Message-Driven EJB:
CacheUpdateBean is unable to connect to the JMS
destination: securityChanges. The EJB container will automatically attempt
to re-establish the connection with the JMS s
erver. This warning may occur during WebLogic Cluster start-up if the JMS
destination is located on another WebLogic Ser
ver instance. When the JMS server connection is re-established, the
Message-Driven EJB will again receive JMS messages.
The Error was:
weblogic.jms.common.JMSException: Error creating session
Start server side stack trace:
weblogic.jms.common.JMSException: Error creating session
at weblogic.jms.backend.BEManager.sessionCreate(BEManager.java:121)
at weblogic.jms.backend.BEManager.invoke(BEManager.java:219)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:149
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture(DispatcherImpl.jav
a:300)
at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
----------- Linked Exception -----------
weblogic.jms.dispatcher.DispatcherException: Dispatcher not found in jndi:
Prod1, javax.naming.NameNotFoundException: Un
able to resolve weblogic.jms.S:Prod1. Resolved: 'weblogic.jms'
Unresolved:'S:Prod1' ; remaining name ''
at
weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager
.java:260)
at
weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(DispatcherM
anager.java:307)
at weblogic.jms.backend.BEManager.sessionCreate(BEManager.java:117)
at weblogic.jms.backend.BEManager.invoke(BEManager.java:219)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:149
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture(DispatcherImpl.jav
a:300)
at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace
------- snip -------------
If I deploy the CacheUpdateBean bean to ProdJMS itself, I don't have this
exception. The weird thing is that when I check the JDNI tree of Prod1 I'm
actually able to see "weblogic.jms.S:Prod1", which is the name that seems
not to be binded. Again, if I deploy the JMS Server to Prod1, for example,
everything works fine. If I deploy the JMS server to a server with only the
JMS server I get the mentioned JNDI exception.
I would appreciate if you could give me help me solving this problem.
Thanks in a dvance for any help.
Andre Mendonca

First of all, my envinronment is Weblogic 6.1 sp2, JDK 1.3.1, Windows
My current production and test environments consist, each one of them, of
clusters with one admin server (ProdAdmin) and two managed servers (Prod1
and Prod2). One of the managed servers (Prod1) is the server to which the
JMS server is deployed and everything works fine.
Now I'm trying to add another managed server to the cluster. The idea isto
target the JMS Server (and nothing else) to this node. We don't want theJMS
server to be running in Prod1 and the new server, named ProdJMS, won'teven
have any deployed beans or the startup class targeted to it. Just the JMS
server. Here our problems start.
I'm able to start this ProdJMS node with no problems. However, when Istart
Prod1 it seems that the JMS server is not binded. This is the exception
we're getting when a message-driven bean is being deployed (I get the same
exception trying to create other):1. Make sure that you are using a dif multicast address for each cluster
2. Remove the JMS from Prod1 -- double check this!
3. Stop Prod1 and Prod2
4. Start the ProdJMS
5. Restart Prod1 and Prod2
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Andre Mendonca" <[email protected]> wrote in message
news:[email protected]...
Hello,
------- snip -------------
<May 21, 2002 12:11:42 PM EDT> <Warning> <EJB> <The Message-Driven EJB:
CacheUpdateBean is unable to connect to the JMS
destination: securityChanges. The EJB container will automatically attempt
to re-establish the connection with the JMS s
erver. This warning may occur during WebLogic Cluster start-up if the JMS
destination is located on another WebLogic Ser
ver instance. When the JMS server connection is re-established, the
Message-Driven EJB will again receive JMS messages.
The Error was:
weblogic.jms.common.JMSException: Error creating session
Start server side stack trace:
weblogic.jms.common.JMSException: Error creating session
atweblogic.jms.backend.BEManager.sessionCreate(BEManager.java:121)
at weblogic.jms.backend.BEManager.invoke(BEManager.java:219)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:149
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture(DispatcherImpl.jav
a:300)
at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
----------- Linked Exception -----------
weblogic.jms.dispatcher.DispatcherException: Dispatcher not found in jndi:
Prod1, javax.naming.NameNotFoundException: Un
able to resolve weblogic.jms.S:Prod1. Resolved: 'weblogic.jms'
Unresolved:'S:Prod1' ; remaining name ''
at
weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager
.java:260)
at
weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(DispatcherM
anager.java:307)
atweblogic.jms.backend.BEManager.sessionCreate(BEManager.java:117)
at weblogic.jms.backend.BEManager.invoke(BEManager.java:219)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:149
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture(DispatcherImpl.jav
a:300)
at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace
------- snip -------------
If I deploy the CacheUpdateBean bean to ProdJMS itself, I don't have this
exception. The weird thing is that when I check the JDNI tree of Prod1 I'm
actually able to see "weblogic.jms.S:Prod1", which is the name that seems
not to be binded. Again, if I deploy the JMS Server to Prod1, for example,
everything works fine. If I deploy the JMS server to a server with onlythe
JMS server I get the mentioned JNDI exception.
I would appreciate if you could give me help me solving this problem.
Thanks in a dvance for any help.
Andre Mendonca

JMSHelper throws 'JMS server is not targetted' creating distributed queue

I am trying to use the 8.1 weblogic.jms.extensions.JMSHelper to create a distributed queue. The target JMS servers are all migratable servers. When calling method createDistributedQueueAsync() I get a JMSException thrown compaining that the [first] JMS server is not targetted. Looking at the code provided in [http://forums.bea.com/bea/thread.jspa?messageID=200023386] which is based on the JMSHelper class source, the exception may be thrown because the target MBean is of class MigratableTargetMBean, whereas the JMSHelper is expecting class TargetMBean. Yet, the 9.0 documentation (which at least documents it) suggests that MigratableTargetMBean is derived from TargetMBean
          Does anyone have experience of this issue or its resolution, short of crafting the code by hand as per the above-referenced reply?

Hi,
Just to remember the configuration: 2 managed servers configured as cluster that should be deployed on 2 different machine.
Following summary of the tests:
     - node manager + admin server + 1 managed server running on the first machine --> server failed to init with error "Server is not in the majority cluster partition"
     - node manager + admin server + 2 managed servers running on the one machine --> servers are running without errors
     - node manager + admin server + 1 managed server running on the first machine / node manager runs on the second machine --> server on the first machine runs without errors without the famous error ' Server is not in the majority cluster partition'.
Bottom line, seems that if the node manager is not running on the remote machine, the cluster is not in a stable state and so the single managed server failed to initialize.
Is it according the documentation / expectations ?
Thanks,
Yaakov

What is the association between JMS Server and JMS Module in weblogic 10?

Hi,
I have a created a ConnectionFactory, Queue, Topic under JMS Modules in Weblogic Server 10 using admin console.
And I have created a JMS Server and Targetted to the current running server (Admin Server).
But when I run the Queue Sender program it is unable to LookUP the jndi which I gave for Queue.
queue = (Queue) initialContext.lookup("jndi_queue");
Exception:
javax.naming.NameNotFoundException: Unable to resolve 'jndi_queue'.
But I configured this jndi name when I create the Queue in JMS Module in Weblogic Server 10.
How JMS Module and JMS server are associated.
My Doubt is if i have several JMS Modules and only one JMS Server created then how does the JMS Server identifies which Queue/Topic belongs to which JMS Module????
Please advice.
Thanks....

Hi,
Once you have JMS servers configured:
Step 1: Target the JMS configuration module to the cluster that will host the destination, or, if not using clustering, target the module to the individual WL server that will host the JMS server.
Step 2: Configure a "subdeployment" for the module and set it to reference the exact JMS server(s) that will host the destination. If you're using a distributed desitnation, you can specify multiple JMS servers, if you're using a regular destination, only specify a single destination.
Step 3: Create a destination resource in the module, and set its subdeployment to the subdeployment you specified in step 1 (the console calls this "advanced targeting"). As a best practice avoid the "default targeting" option for the resource - always choose subdeployment (advanced) targeting.
For more information, reference the "best practices" chapter of the JMS configuration guide:
http://download.oracle.com/docs/cd/E14571_01/web.1111/e13738/best_practice.htm#CACJCGHG
I also I highly recommend the JMS chapter of the book "Professional Oracle WebLogic".
Hope this helps,
Tom

SAF JMS Module Targeting in a cluster

Hi, I'm having a bit of trouble working out the best way of configuring my SAF modules in a clustered environment.
I have one cluster (Cluster1) of 4 JVM's which host a distributed destination and a second cluster (Cluster2) of 4 JVM's which host another distributed destination.
The UDD in Cluster2 is where the messages placed on the UDD in Cluster1 should be sent to by the SAF Agent.
SAF agents are easy, just create one for each of the 4 JVM's in Cluster1.
The bit I'm having trouble with is how to create my JMS module using the best practise approaches to hold the RemoteSAFContext and SAFImportedDestinations and where to target the resources.
RemoteSAFContext gets targeted to the cluster, but do I create an entry for SAFImportedDestinations for each of the 4 JVM's in the cluster and then target that at the corresponding subdeployment, or just create one entry for the SAFImportedDestination and target that at the whole cluster?
I'm probably making this much harder than it actually is, but if anyone has any suggestions that would be great.
Pete
Edited by: Pete.Inman on Feb 4, 2010 2:45 PM

or just create one entry for the SAFImportedDestination and target that at the whole cluster?Yes and no. Yes, create one entry. No, please don't target it to the whole cluster -- as that can work, but there be dragons. I recommend following the documented [ JMS Configuration Best Practices | http://download.oracle.com/docs/cd/E15523_01/web.1111/e13738/best_practice.htm#CACJCGHG ] -- namely:
(1) Create (or re-use) a custom store per server, targeted at the local default migratable target, and create (or re-use) a SAF agent per server that references the local store and that targets the same migratable target as the local store. Set a quota on each SAF agent (always always always set quotas).
(2) Create a single module and target to SAF cluster.
(3) Create a single subdeployment for the module, and populate with the exact names of the SAF agents from step 1
(4) Configure SAF Context in the module.
(5) Configure imported destination in the module, reference the SAF context, and target it to the subdeployment defined in step 3.
Tom
PS. Please post future JMS related questions in the WebLogic Server - JMS newsgroup...
Edited by: TomB on Feb 4, 2010 7:42 PM

MDBs failed to connect to remote JMS server

Hi,
          We currently have 2 clusters: one is a regular cluster (cluster1) and the other is JMS cluster (cluster2). Our JMS server and filestore are targeted to a migratable server in JMS cluster.
          In our weblogic-ejb-jar.xml, we added element <provider-url> to the <message-driven-descriptor> to allow JMS remote connection as follows:
          <weblogic-enterprise-bean>
               <ejb-name>MyBean</ejb-name>
               <message-driven-descriptor>
                    <destination-jndi-name>MyTopic</destination-jndi-name>
          <provider-url>t3://myhost:19009,myhost:19011</provider-url>
          <connection-factory-jndi-name>MyConnectionFactory</connection-factory-jn
          di-name>
               </message-driven-descriptor>
          </weblogic-enterprise-bean>
          When we deployed our application, the Connection Status of MyBean showed "disconnected". I have tried different values (t3://myhost:19009;t3://myhost:19011) and
          (t3://myhost:19009) but got the same result.
          When I re-targeted the JMS server and filestore to a regular server (instead of migratable server), I was able to connect remotely. But because we want to be able to migrate our JMS server (auto and manually), I have to target it to a migratable server.
          I could not figure out why my MDBs failed to connect to a remote JMS server when it is targeted to a migratable server? Is there a restriction that we have to target to a regular server in order to connect remotely or I'm doing something wrong?
          Any help would be greatly appreciated.
          Thanks,
          Thao

I'm using WL9.2 and my migratable server is actually up and running (is that what you mean about booted?).                    I meant checking your log files to make sure that the JMS server itself actually booted, not checking that the host WL server was up. (For example you should see INFO messages indicating that the JMS server has loaded "X" records from its persistent store).
          >>> Could you elaborate on the known problem?
          9.x MDBs have special code for enhanced handling of remote distributed destinations. I'm guessing that this code is somehow causing problems when the remote JMS server is migratable. I don't have enough information to elaborate further than that.
          >>> What else I can try?
          Beyond contacting customer support, I'm not sure.
          Tom

JMS Server deployed to cluster of servers

Hey guys,
I was trying to deploy a JMS server to a cluster of servers and in the target section there wasn't an option for the cluster. They had an option for each individual server and another migratable version of the server. If I target one of the migratable servers in the cluster will it apply to all of the servers?
I read the following passage in the weblogic documents:
Obtain a Clustered JMS Licence
In order to implement JMS clustering, you must have a valid clustered JMS license, which allows a connection factory and a destination to be on different WebLogic Server instances. A clustered JMS license is also required to use the Foreign JMS Providers feature, as described in "Simple Access to Remote or Foreign JMS Providers" in the Administration Console Online Help. If you do not have a valid clustered JMS license, contact your BEA sales representative.
If i'm just building a model does this apply to me?
Thanks

continued reading to clarify. Problem solved, thanks for looking

Jms server

Hello:
          In a cluster with nodes from different subnet ( with weblogic 7.0 sp1)
          there is an application deployed with mdb's. The jms server is not
          clustered and is targetted only on one server in the cluster.
          When the second node is starting, it is not able to comminicate with the
          jms server running in the other node. The connection factories are
          clustered.
          What I may be doing wrong.
          regards,
          Ravi


I suggest reading the cluster documentation,
          and posting questions to the clustering or jndi newsgroup.
          Cluster configuration is outside the scope of JMS per se.
          Ravi Krishnamurthy wrote:
          > Hello:
          > If the cluster multicast address is set to default it works fine. When it is
          > set to 239.192.24.123 it does not work.
          >
          > regards,
          > Ravi
          >
          > Ravi Krishnamurthy wrote:
          >
          >
          >>Hello:
          >>In a cluster with nodes from different subnet ( with weblogic 7.0 sp1)
          >>there is an application deployed with mdb's. The jms server is not
          >>clustered and is targetted only on one server in the cluster.
          >>
          >>When the second node is starting, it is not able to comminicate with the
          >>jms server running in the other node. The connection factories are
          >>clustered.
          >>
          >>What I may be doing wrong.
          >>
          >>regards,
          >>Ravi
          >
          >

Role of the JMS server

Sorry for posting this kind of question, but after reading several times BEA documentation regarding JMS and clustering, I still do not understand the purpose of a JMS server.
          Questions:
          1. What is really a JMS server for? What is its purpose?
          2. Do I need to create and deploy one JMS server per node in a cluster, or I just need one?
          Thank you for your assistance.

While a DD is location transparent within a cluster, no matter which nodes it runs on, a DD is not required to get location transparency. Any physical destination with a JNDI name is transparently accessable from any server in the same cluster, or any remote client connected to any server in the same cluster - just by looking up the JNDI name. This works the same way other JNDI advertised resources work (EJBs, JDBC connections, etc.)
          A DD is useful for load-balancing, performance, and high-availability. It does this by providing a virtual destination that consists of multiple physical destinations. There is usually little point in a DD that only consists of a single destination, or that has all of its destinations on a single host machine/WL server. To get the full use out of a DD, configure a JMS server on more than one cluster node, and configure the DD to use a physical destination on each one.
          Whether or not you choose to use a DD is application specific. I estimate that the majority of applications don't, but performance sensitive applications, or apps that have high HA requirements typically do. Note that DD apps must typically be able to tolerate out-of-order message processing due to the very nature of DDs (WL 9.0s unique "unit-of-order" feature is designed to address this issue).
          Tom

JNDI Names of JMS server's queue not replicating to cluster

          Am having some trouble configuring a JMS Server and Queues in a clustered development
          environment. It is a simple cluster of 2 servers (Server1 and Server2) both on
          a single machine.
          The "JobServer" JMS Server is targeted to "Server1 (migratable)". All the JNDI
          names for the Queues appear in the JNDI tree of Server1, but not in Server2.
          When the sending of a message is attempted on Server2, the following occurs:
          javax.naming.NameNotFoundException: While trying to lookup 'jms.STARSIIPostQueue'
          didn't find subcontext 'jms' Resolved ; remaining name 'jms/STARSIIPostQueue'
          at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:858)
          This may be a problem with the cluster configuration, but I haven't been able
          to see anything wrong with it.
          Any and all help will be appreciated.
          There is the Config.xml file:
          <?xml version="1.0" encoding="UTF-8"?>
          <Domain ConfigurationVersion="8.1.2.0" Name="mydomain">
          <Server ExtraEjbcOptions="-J-mx512m" ListenAddress=""
          ListenPort="7001" Name="myserver" NativeIOEnabled="true"
          ServerVersion="8.1.2.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
          <SSL Enabled="false" HostnameVerificationIgnored="false"
          IdentityAndTrustLocations="KeyStores" ListenPort="7002" Name="myserver"/>
          <Log Name="myserver" NumberOfFilesLimited="true"/>
          </Server>
          <Security Name="mydomain"
          PasswordPolicy="wl_default_password_policy"
          Realm="wl_default_realm" RealmSetup="true">
          <weblogic.security.providers.authentication.DefaultAuthenticator
          Name="Security:Name=myrealmDefaultAuthenticator" Realm="Security:Name=myrealm"/>
          <weblogic.security.providers.authentication.DefaultIdentityAsserter
          ActiveTypes="AuthenticatedUser"
          Name="Security:Name=myrealmDefaultIdentityAsserter" Realm="Security:Name=myrealm"/>
          <weblogic.security.providers.authorization.DefaultRoleMapper
          Name="Security:Name=myrealmDefaultRoleMapper" Realm="Security:Name=myrealm"/>
          <weblogic.security.providers.authorization.DefaultAuthorizer
          Name="Security:Name=myrealmDefaultAuthorizer" Realm="Security:Name=myrealm"/>
          <weblogic.security.providers.authorization.DefaultAdjudicator
          Name="Security:Name=myrealmDefaultAdjudicator"
          Realm="Security:Name=myrealm" RequireUnanimousPermit="false"/>
          <weblogic.security.providers.credentials.DefaultCredentialMapper
          Name="Security:Name=myrealmDefaultCredentialMapper" Realm="Security:Name=myrealm"/>
          <weblogic.management.security.authentication.UserLockoutManager
          Name="Security:Name=myrealmUserLockoutManager" Realm="Security:Name=myrealm"/>
          <weblogic.management.security.Realm
          Adjudicator="Security:Name=myrealmDefaultAdjudicator"
          Auditors="Security:Name=myrealmSTARSIIAuditor"
          AuthenticationProviders="Security:Name=myrealmSTARSIIAuthenticator|Security:Name=myrealmDefaultAuthenticator|Security:Name=myrealmDefaultIdentityAsserter"
          Authorizers="Security:Name=myrealmDefaultAuthorizer|Security:Name=myrealmSTARSIIAuthorizer"
          CredentialMappers="Security:Name=myrealmDefaultCredentialMapper"
          DefaultRealm="true" DisplayName="myrealm"
          FullyDelegateAuthorization="true"
          Name="Security:Name=myrealm"
          RoleMappers="Security:Name=myrealmDefaultRoleMapper" UserLockoutManager="Security:Name=myrealmUserLockoutManager"/>
          <gov.fns.starsii.common.security.authentication.STARSIIAuthenticator
          ControlFlag="SUFFICIENT"
          Name="Security:Name=myrealmSTARSIIAuthenticator" Realm="Security:Name=myrealm"/>
          <gov.fns.starsii.common.security.authorization.STARSIIAuthorizer
          ExemptUri="/common/,/images/,/warning.do,/login.do"
          Name="Security:Name=myrealmSTARSIIAuthorizer"
          PolicyDeploymentEnabled="false"
          Realm="Security:Name=myrealm" Verbose="false" denyPermNotFound="true"/>
          <gov.fns.starsii.common.security.audit.STARSIIAuditor
          Name="Security:Name=myrealmSTARSIIAuditor" Realm="Security:Name=myrealm"/>
          </Security>
          <EmbeddedLDAP
          Credential="{3DES}aD+gV9rRggnoShH/kWurILaHTBP/z0jVoZHtp/hU1xI=" Name="mydomain"/>
          <SecurityConfiguration
          Credential="{3DES}mhxP4PeuUHmoX6Aggpj5SNB+AX16Gaol8dOfUzXu7xM8CFNASyNdYIOoqtlqPAZvfZgB14KBtY8MkdKGu/iWFq1xQ07walY8"
          Name="mydomain" RealmBootStrapVersion="1"/>
          <Realm FileRealm="wl_default_file_realm" Name="wl_default_realm"/>
          <FileRealm Name="wl_default_file_realm"/>
          <PasswordPolicy Name="wl_default_password_policy"/>
          <JDBCConnectionPool
          DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          Name="STARSII BRSB Pool"
          Password="{3DES}9pslRpr051lR9/NEKdanag=="
          Properties="user=brsbapp;portNumber=1433;databaseName=brsbdev;serverName=str2-dev-db"
          Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          <JDBCTxDataSource JNDIName="jdbc/StarsIIDS" Name="StarsIIDS"
          PoolName="STARSII Store Pool" Targets="MyCluster"/>
          <JDBCTxDataSource JNDIName="jdbc/TXStarsIIDS" Name="TXStarsIIDS"
          PoolName="STARSII Store Pool" Targets="MyCluster"/>
          
          <MailSession JNDIName="mail/STARSIIMailSession"
          Name="STARSIIMailSession" Properties="mail.host=str2-dev-prj" Targets="myserver"/>
          <JDBCConnectionPool
          DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          Name="STARSII Store Pool"
          Password="{3DES}nKggeFT8wZkm0R9H8mXaEQ=="
          Properties="user=storeapp;portNumber=1433;databaseName=storedev;serverName=str2-dev-db"
          Targets="MyCluster"
          TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          <JDBCConnectionPool
          DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          Name="AffTest" Password=""
          Properties="user=sa;portNumber=1433;databaseName=affTest;serverName=AFRANK\AFRANK"
          Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://AFRANK\AFRANK:1433"/>
          <JDBCTxDataSource JNDIName="jdbc/AffTest" Name="AffTest"
          PoolName="AffTest" Targets=""/>
          <JDBCConnectionPool DriverName="weblogic.jdbcspy.SpyDriver"
          Name="Spy STARSII BRSB Pool"
          Password="{3DES}9pslRpr051lR9/NEKdanag=="
          Properties="user=brsbapp;portNumber=1433;databaseName=brsbdev;serverName=str2-dev-db"
          Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:spy:{jdbc:bea:sqlserver://str2-dev-db:1433};log=(file)C:\cvsrepo\sql.log"/>
          <JDBCConnectionPool
          DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          Name="STARSII Store Pool 2"
          Password="{3DES}nKggeFT8wZkm0R9H8mXaEQ=="
          Properties="user=storeapp;portNumber=1433;databaseName=storedev;serverName=str2-dev-db"
          Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          <JDBCTxDataSource JNDIName="jdbc/StarsIIDS2" Name="StarsIIDS2"
          PoolName="STARSII Store Pool" Targets=""/>
          <JDBCConnectionPool
          DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          Name="STARSII Stars Pool"
          Password="{3DES}tjstL+8fUvdPQzqhNcCYGA=="
          Properties="user=starsapp;portNumber=1433;databaseName=stars;serverName=str2-dev-db"
          Targets="MyCluster"
          TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          <Machine Name="MachineA">
          <NodeManager DebugEnabled="true" ListenPort="5555" Name="MachineA"/>
          </Machine>
          <Server Cluster="MyCluster" ExpectedToRun="false"
          ExtraEjbcOptions="-J-mx521m" JDBCLoggingEnabled="true"
          ListenAddress="10.0.0.14" ListenPort="7002" Machine="MachineA"
          Name="Server1" ServerVersion="8.1.2.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
          <ServerDebug Name="Server1"/>
          <SSL IdentityAndTrustLocations="KeyStores" Name="Server1"/>
          <KernelDebug Name="Server1"/>
          <Log Name="Server1"/>
          <ServerStart Name="Server1"
          OutputFile="C:\bea\user_projects\domains\mydomain\.\NodeManagerClientLogs\mydomain_Server1\startServer_05_05_2004-12_50_56-4.log"
          Password="{3DES}js4NnTcuqRE15gEGfNTu4Q==" Username="system"/>
          <WebServer Name="Server1"/>
          <COM Name="Server1"/>
          <IIOP Name="Server1"/>
          <JTAMigratableTarget Name="Server1" UserPreferredServer="Server1"/>
          <JTARecoveryService Name="Server1"/>
          </Server>
          <Cluster ClusterAddress="10.0.0.14, 10.0.2.15"
          MulticastAddress="226.0.0.244" Name="MyCluster"/>
          <Server Cluster="MyCluster" ExpectedToRun="false"
          ExtraEjbcOptions="-J-mx521m" ListenAddress="10.0.2.15"
          ListenPort="7002" Machine="MachineB" Name="Server2"
          ServerVersion="8.1.2.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
          <ServerDebug Name="Server2"/>
          <SSL IdentityAndTrustLocations="KeyStores" Name="Server2"/>
          <KernelDebug Name="Server2"/>
          <Log Name="Server2"/>
          <ServerStart Name="Server2"
          Password="{3DES}js4NnTcuqRE15gEGfNTu4Q==" Username="system"/>
          <WebServer Name="Server2"/>
          <COM Name="Server2"/>
          <IIOP Name="Server2"/>
          <JTAMigratableTarget Name="Server2" UserPreferredServer="Server2"/>
          <JTARecoveryService Name="Server2"/>
          </Server>
          <MigratableTarget Cluster="MyCluster" Name="Server1 (migratable)"
          Notes="This is a system generated default migratable target for a server.
          Do not delete manually." UserPreferredServer="Server1"/>
          <MigratableTarget Cluster="MyCluster" Name="Server2 (migratable)"
          Notes="This is a system generated default migratable target for a server.
          Do not delete manually." UserPreferredServer="Server2"/>
          <Application Deployed="true" Name="STARSII"
          Path="C:\cvsrepo\STARSII\STARSII" StagingMode="nostage" TwoPhase="true">
          <EJBComponent Name="../brsbMessage" Targets="MyCluster" URI="../brsbMessage"/>
          <EJBComponent Name="../brsbSession" Targets="MyCluster" URI="../brsbSession"/>
          <EJBComponent Name="../commonSession" Targets="MyCluster" URI="../commonSession"/>
          <EJBComponent Name="../complianceMessage" Targets="MyCluster" URI="../complianceMessage"/>
          <EJBComponent Name="../complianceSession" Targets="MyCluster" URI="../complianceSession"/>
          <EJBComponent Name="../starsiiEntity" Targets="MyCluster" URI="../starsiiEntity"/>
          <EJBComponent Name="../storeSession" Targets="MyCluster" URI="../storeSession"/>
          <WebAppComponent Name="/brsb" Targets="MyCluster" URI="../brsbWebApp"/>
          <WebAppComponent Name="/compliance" Targets="MyCluster" URI="../complianceWebApp"/>
          <WebAppComponent Name="/common" Targets="MyCluster" URI="../mainWebApp"/>
          <WebAppComponent Name="/store" Targets="MyCluster" URI="../storeWebApp"/>
          </Application>
          <Application Name="AffWebApp" Path="C:\cvsrepo\STARSII"
          StagingMode="nostage" TwoPhase="true">
          <WebAppComponent Name="AffWebApp" Targets="" URI="AffWebApp"/>
          </Application>
          <Application Name="activeportal"
          Path="C:\bea\user_projects\domains\mydomain\myserver\upload"
          StagingMode="nostage" TwoPhase="true">
          <WebAppComponent Name="activeportal" Targets="" URI="activeportal.war"/>
          </Application>
          <JTA Name="mydomain" TimeoutSeconds="300"/>
          <JMSServer Name="JobServer" Targets="Server1 (migratable)">
          <JMSQueue CreationTime="1072820642598"
          JNDIName="jms/STARSIIJobQueue" Name="STARSIIJobQueue"/>
          <JMSQueue CreationTime="1072820669345"
          JNDIName="jms/STARSIIPostQueue" Name="STARSIIPostQueue"/>
          <JMSQueue CreationTime="1088000795852"
          JNDIName="jms/STARSIIValidationQueue" Name="STARSIIValidationQueue"/>
          <JMSQueue CreationTime="1072820687125"
          JNDIName="jms/STARSIIErrorQueue" Name="STARSIIErrorQueue"/>
          <JMSQueue CreationTime="1072820687125"
          JNDIName="jms/STARSIIEmailQueue" Name="STARSIIEmailQueue"/>
          <JMSQueue CreationTime="1072820687225"
          JNDIName="jms/STARSIIEBTStateQueue" Name="STARSIIEBTStateQueue"/>
          <JMSQueue CreationTime="1072820687325"
          JNDIName="jms/STARSIIRFIQueue" Name="STARSIIRFIQueue"/>
          <JMSQueue CreationTime="1072820687425"
          JNDIName="jms/STARSIIRedeQueue" Name="STARSIIRedeQueue"/>
          <JMSQueue CreationTime="1072820687525"
          JNDIName="jms/STARSIIWatchListQueue" Name="STARIIWatchListQueue"/>
          <JMSQueue CreationTime="1072820687625"
          JNDIName="jms/STARSIIDeleteTransFileQueue" Name="STARSIIDeleteTransFileQueue"/>
          <JMSQueue CreationTime="1072820687725"
          JNDIName="jms/STARSIIUpdateAMRQueue" Name="STARSIIUpdateAMRQueue"/>
          <JMSQueue CreationTime="1072820687825"
          JNDIName="jms/STARSIIVPPExtractQueue" Name="STARSIIVPPExtractQueue"/>
          <JMSQueue CreationTime="1072820687925"
          JNDIName="jms/STARSIISIFSUploadQueue" Name="STARSIISIFSUploadQueue"/>
          <JMSQueue CreationTime="1072820688025"
          JNDIName="jms/STARSIIMARSQueue" Name="STARSIIMARSQueue"/>
          <JMSQueue CreationTime="1072820688125"
          JNDIName="jms/STARSIIFRBRichmondExtractQueue" Name="STARSIIFRBRichmondExtractQueue"/>
          <JMSQueue CreationTime="1072820688225"
          JNDIName="jms/STARSIICOTSExtractQueue" Name="STARSIICOTSExtractQueue"/>
          <JMSQueue CreationTime="1072820688325"
          JNDIName="jms/STARSIIVPPUploadQueue" Name="STARSIIVPPUploadQueue"/>
          </JMSServer>
          <Machine Name="MachineB">
          <NodeManager DebugEnabled="true" Name="MachineB"/>
          </Machine>
          </Domain>


Internally, many BEA developers and testers use various versions
          of XP with clustering on a daily basis. I don't know what
          is unique about your machine. I suggest raising the issue
          with customer support and/or posting to the clustering newsgroup...
          Andy Frank wrote:
          > It would seems that my OS and the MultiCast config are to blame. The MultiCast
          > test utility worked fine the Win2K machines I tried. Think I will take another
          > look at MS KB article 827536 and/or think about another dev OS.
          >
          > "Andy Frank" <[email protected]> wrote:
          >
          >>Tom,
          >>Thanks for this info.
          >>
          >>My servers don't look like they are running in different subnets (had
          >>a friend
          >>look this over and he concurs).
          >>
          >>My network admin says he hasn't blocked multicast traffic.
          >>
          >>I think the MultiCast test utility is telling me that I have some kind
          >>of multicast
          >>config problem. Output follows:
          >>
          >>------ Begin MultiCast test utility output: ------
          >>C:\bea\weblogic81\server\bin>java utils.MulticastTest -N server200 -A
          >>237.155.15
          >>5.1 -t 15
          >>***** WARNING ***** WARNING ***** WARNING *****
          >>Do NOT use the same multicast address as a running WLS cluster.
          >>
          >>
          >>Starting test. Hit any key to abort
          >>
          >>
          >>Using multicast address 237.155.155.1:7001
          >>Will send messages under the name server200 every 2 seconds
          >>Will print warning every 15 seconds if no messages are received
          >>
          >> I (server200) sent message num 1
          >> I (server200) sent message num 2
          >> I (server200) sent message num 3
          >> I (server200) sent message num 4
          >> I (server200) sent message num 5
          >> I (server200) sent message num 6
          >> I (server200) sent message num 7
          >>java.net.SocketTimeoutException: Receive timed out
          >> at java.net.PlainDatagramSocketImpl.receive(Native Method)
          >> at java.net.DatagramSocket.receive(DatagramSocket.java:680)
          >> at utils.MulticastTest$Receiver.run(MulticastTest.java:304)
          >> I (server200) sent message num 8
          >> I (server200) sent message num 9
          >> I (server200) sent message num 10
          >> I (server200) sent message num 11
          >> I (server200) sent message num 12
          >>------ End MultiCast test utility output: ------
          >>
          >>No "Received message X from server200" messages. I think I need to look
          >>into
          >>configuring multicast communications on my OK (Windows XP Pro, ver 2002
          >>SP1).
          >>I did see MS KB article 827536 about "An IP multicast may not be sent
          >>correctly
          >
          >>from Windows XP or from Windows Server 2003" (I do have 2 network adapters),
          >
          >>but
          >>the resolution scared me some.
          >>
          >>Think I will try some things out on another OS and see what that gets
          >>me.
          >>
          >>Any other thoughts on this will be appreciated.
          >>
          >>
          >>Tom Barnes wrote:
          >>
          >>>I too suspect something is going wrong with clustering, I wonder
          >>>if the servers are running in different subnets (even though
          >>>they are on the same box) and/or your network admin has
          >>>blocked multicast traffic.
          >>>
          >>>The MultiCast test utility should help narrow things down:
          >>>
          >>>http://e-docs.bea.com/wls/docs81/admin_ref/utils.html#1199798
          >>>
          >>>Tom
          >>>
          >>>Andy Frank wrote:
          >>>
          >>>
          >>>>Am having some trouble configuring a JMS Server and Queues in a clustered
          >>>
          >>>development
          >>>
          >>>>environment. It is a simple cluster of 2 servers (Server1 and Server2)
          >>>
          >>>both on
          >>>
          >>>>a single machine.
          >>>>
          >>>>The "JobServer" JMS Server is targeted to "Server1 (migratable)".
          >>
          >>>All the JNDI
          >>>
          >>>>names for the Queues appear in the JNDI tree of Server1, but not in
          >>>
          >>>Server2.
          >>>
          >>>>When the sending of a message is attempted on Server2, the following
          >>>
          >>>occurs:
          >>>
          >>>>javax.naming.NameNotFoundException: While trying to lookup 'jms.STARSIIPostQueue'
          >>>>didn't find subcontext 'jms' Resolved ; remaining name 'jms/STARSIIPostQueue'
          >>>> at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:858)
          >>>>
          >>>>This may be a problem with the cluster configuration, but I haven't
          >>>
          >>>been able
          >>>
          >>>>to see anything wrong with it.
          >>>>
          >>>>Any and all help will be appreciated.
          >>>>
          >>>>There is the Config.xml file:
          >>>><?xml version="1.0" encoding="UTF-8"?>
          >>>><Domain ConfigurationVersion="8.1.2.0" Name="mydomain">
          >>>> <Server ExtraEjbcOptions="-J-mx512m" ListenAddress=""
          >>>> ListenPort="7001" Name="myserver" NativeIOEnabled="true"
          >>>> ServerVersion="8.1.2.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
          >>>> <SSL Enabled="false" HostnameVerificationIgnored="false"
          >>>> IdentityAndTrustLocations="KeyStores" ListenPort="7002"
          >>>
          >>>Name="myserver"/>
          >>>
          >>>> <Log Name="myserver" NumberOfFilesLimited="true"/>
          >>>> </Server>
          >>>> <Security Name="mydomain"
          >>>> PasswordPolicy="wl_default_password_policy"
          >>>> Realm="wl_default_realm" RealmSetup="true">
          >>>> <weblogic.security.providers.authentication.DefaultAuthenticator
          >>>> Name="Security:Name=myrealmDefaultAuthenticator" Realm="Security:Name=myrealm"/>
          >>>>
          >>>> <weblogic.security.providers.authentication.DefaultIdentityAsserter
          >>>> ActiveTypes="AuthenticatedUser"
          >>>> Name="Security:Name=myrealmDefaultIdentityAsserter" Realm="Security:Name=myrealm"/>
          >>>> <weblogic.security.providers.authorization.DefaultRoleMapper
          >>>> Name="Security:Name=myrealmDefaultRoleMapper" Realm="Security:Name=myrealm"/>
          >>>> <weblogic.security.providers.authorization.DefaultAuthorizer
          >>>> Name="Security:Name=myrealmDefaultAuthorizer" Realm="Security:Name=myrealm"/>
          >>>> <weblogic.security.providers.authorization.DefaultAdjudicator
          >>>> Name="Security:Name=myrealmDefaultAdjudicator"
          >>>> Realm="Security:Name=myrealm" RequireUnanimousPermit="false"/>
          >>>> <weblogic.security.providers.credentials.DefaultCredentialMapper
          >>>> Name="Security:Name=myrealmDefaultCredentialMapper" Realm="Security:Name=myrealm"/>
          >>>> <weblogic.management.security.authentication.UserLockoutManager
          >>>> Name="Security:Name=myrealmUserLockoutManager" Realm="Security:Name=myrealm"/>
          >>>> <weblogic.management.security.Realm
          >>>> Adjudicator="Security:Name=myrealmDefaultAdjudicator"
          >>>> Auditors="Security:Name=myrealmSTARSIIAuditor"
          >>>> AuthenticationProviders="Security:Name=myrealmSTARSIIAuthenticator|Security:Name=myrealmDefaultAuthenticator|Security:Name=myrealmDefaultIdentityAsserter"
          >>>> Authorizers="Security:Name=myrealmDefaultAuthorizer|Security:Name=myrealmSTARSIIAuthorizer"
          >>>> CredentialMappers="Security:Name=myrealmDefaultCredentialMapper"
          >>>> DefaultRealm="true" DisplayName="myrealm"
          >>>> FullyDelegateAuthorization="true"
          >>>> Name="Security:Name=myrealm"
          >>>> RoleMappers="Security:Name=myrealmDefaultRoleMapper" UserLockoutManager="Security:Name=myrealmUserLockoutManager"/>
          >>>>
          >>>> <gov.fns.starsii.common.security.authentication.STARSIIAuthenticator
          >>>> ControlFlag="SUFFICIENT"
          >>>> Name="Security:Name=myrealmSTARSIIAuthenticator" Realm="Security:Name=myrealm"/>
          >>>> <gov.fns.starsii.common.security.authorization.STARSIIAuthorizer
          >>>> ExemptUri="/common/,/images/,/warning.do,/login.do"
          >>>> Name="Security:Name=myrealmSTARSIIAuthorizer"
          >>>> PolicyDeploymentEnabled="false"
          >>>> Realm="Security:Name=myrealm" Verbose="false" denyPermNotFound="true"/>
          >>>> <gov.fns.starsii.common.security.audit.STARSIIAuditor
          >>>> Name="Security:Name=myrealmSTARSIIAuditor" Realm="Security:Name=myrealm"/>
          >>>> </Security>
          >>>> <EmbeddedLDAP
          >>>> Credential="{3DES}aD+gV9rRggnoShH/kWurILaHTBP/z0jVoZHtp/hU1xI="
          >>>
          >>>Name="mydomain"/>
          >>>
          >>>> <SecurityConfiguration
          >>>> Credential="{3DES}mhxP4PeuUHmoX6Aggpj5SNB+AX16Gaol8dOfUzXu7xM8CFNASyNdYIOoqtlqPAZvfZgB14KBtY8MkdKGu/iWFq1xQ07walY8"
          >>>> Name="mydomain" RealmBootStrapVersion="1"/>
          >>>> <Realm FileRealm="wl_default_file_realm" Name="wl_default_realm"/>
          >>>> <FileRealm Name="wl_default_file_realm"/>
          >>>> <PasswordPolicy Name="wl_default_password_policy"/>
          >>>> <JDBCConnectionPool
          >>>> DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          >>>> Name="STARSII BRSB Pool"
          >>>> Password="{3DES}9pslRpr051lR9/NEKdanag=="
          >>>> Properties="user=brsbapp;portNumber=1433;databaseName=brsbdev;serverName=str2-dev-db"
          >>>> Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects"
          >>>
          >>>URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          >>>
          >>>> <JDBCTxDataSource JNDIName="jdbc/StarsIIDS" Name="StarsIIDS"
          >>>> PoolName="STARSII Store Pool" Targets="MyCluster"/>
          >>>> <JDBCTxDataSource JNDIName="jdbc/TXStarsIIDS" Name="TXStarsIIDS"
          >>>> PoolName="STARSII Store Pool" Targets="MyCluster"/>
          >>>> 
          >>>> <MailSession JNDIName="mail/STARSIIMailSession"
          >>>> Name="STARSIIMailSession" Properties="mail.host=str2-dev-prj"
          >>>
          >>>Targets="myserver"/>
          >>>
          >>>> <JDBCConnectionPool
          >>>> DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          >>>> Name="STARSII Store Pool"
          >>>> Password="{3DES}nKggeFT8wZkm0R9H8mXaEQ=="
          >>>> Properties="user=storeapp;portNumber=1433;databaseName=storedev;serverName=str2-dev-db"
          >>>> Targets="MyCluster"
          >>>> TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          >>>> <JDBCConnectionPool
          >>>> DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          >>>> Name="AffTest" Password=""
          >>>> Properties="user=sa;portNumber=1433;databaseName=affTest;serverName=AFRANK\AFRANK"
          >>>> Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects"
          >>>
          >>>URL="jdbc:bea:sqlserver://AFRANK\AFRANK:1433"/>
          >>>
          >>>> <JDBCTxDataSource JNDIName="jdbc/AffTest" Name="AffTest"
          >>>> PoolName="AffTest" Targets=""/>
          >>>> <JDBCConnectionPool DriverName="weblogic.jdbcspy.SpyDriver"
          >>>> Name="Spy STARSII BRSB Pool"
          >>>> Password="{3DES}9pslRpr051lR9/NEKdanag=="
          >>>> Properties="user=brsbapp;portNumber=1433;databaseName=brsbdev;serverName=str2-dev-db"
          >>>> Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects"
          >>>
          >>>URL="jdbc:spy:{jdbc:bea:sqlserver://str2-dev-db:1433};log=(file)C:\cvsrepo\sql.log"/>
          >>>
          >>>> <JDBCConnectionPool
          >>>> DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          >>>> Name="STARSII Store Pool 2"
          >>>> Password="{3DES}nKggeFT8wZkm0R9H8mXaEQ=="
          >>>> Properties="user=storeapp;portNumber=1433;databaseName=storedev;serverName=str2-dev-db"
          >>>> Targets="" TestTableName="SQL SELECT COUNT(*) FROM sysobjects"
          >>>
          >>>URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          >>>
          >>>> <JDBCTxDataSource JNDIName="jdbc/StarsIIDS2" Name="StarsIIDS2"
          >>>> PoolName="STARSII Store Pool" Targets=""/>
          >>>> <JDBCConnectionPool
          >>>> DriverName="weblogic.jdbc.sqlserver.SQLServerDriver"
          >>>> Name="STARSII Stars Pool"
          >>>> Password="{3DES}tjstL+8fUvdPQzqhNcCYGA=="
          >>>> Properties="user=starsapp;portNumber=1433;databaseName=stars;serverName=str2-dev-db"
          >>>> Targets="MyCluster"
          >>>> TestTableName="SQL SELECT COUNT(*) FROM sysobjects" URL="jdbc:bea:sqlserver://str2-dev-db:1433"/>
          >>>> <Machine Name="MachineA">
          >>>> <NodeManager DebugEnabled="true" ListenPort="5555" Name="MachineA"/>
          >>>> </Machine>
          >>>> <Server Cluster="MyCluster" ExpectedToRun="false"
          >>>> ExtraEjbcOptions="-J-mx521m" JDBCLoggingEnabled="true"
          >>>> ListenAddress="10.0.0.14" ListenPort="7002" Machine="MachineA"
          >>>> Name="Server1" ServerVersion="8.1.2.0" StdoutDebugEnabled="true"
          >>>
          >>>StdoutSeverityLevel="64">
          >>>
          >>>> <ServerDebug Name="Server1"/>
          >>>> <SSL IdentityAndTrustLocations="KeyStores" Name="Server1"/>
          >>>> <KernelDebug Name="Server1"/>
          >>>> <Log Name="Server1"/>
          >>>> <ServerStart Name="Server1"
          >>>> OutputFile="C:\bea\user_projects\domains\mydomain\.\NodeManagerClientLogs\mydomain_Server1\startServer_05_05_2004-12_50_56-4.log"
          >>>> Password="{3DES}js4NnTcuqRE15gEGfNTu4Q==" Username="system"/>
          >>>> <WebServer Name="Server1"/>
          >>>> <COM Name="Server1"/>
          >>>> <IIOP Name="Server1"/>
          >>>> <JTAMigratableTarget Name="Server1" UserPreferredServer="Server1"/>
          >>>> <JTARecoveryService Name="Server1"/>
          >>>> </Server>
          >>>> <Cluster ClusterAddress="10.0.0.14, 10.0.2.15"
          >>>> MulticastAddress="226.0.0.244" Name="MyCluster"/>
          >>>> <Server Cluster="MyCluster" ExpectedToRun="false"
          >>>> ExtraEjbcOptions="-J-mx521m" ListenAddress="10.0.2.15"
          >>>> ListenPort="7002" Machine="MachineB" Name="Server2"
          >>>> ServerVersion="8.1.2.0" StdoutDebugEnabled="true" StdoutSeverityLevel="64">
          >>>> <ServerDebug Name="Server2"/>
          >>>> <SSL IdentityAndTrustLocations="KeyStores" Name="Server2"/>
          >>>> <KernelDebug Name="Server2"/>
          >>>> <Log Name="Server2"/>
          >>>> <ServerStart Name="Server2"
          >>>> Password="{3DES}js4NnTcuqRE15gEGfNTu4Q==" Username="system"/>
          >>>> <WebServer Name="Server2"/>
          >>>> <COM Name="Server2"/>
          >>>> <IIOP Name="Server2"/>
          >>>> <JTAMigratableTarget Name="Server2" UserPreferredServer="Server2"/>
          >>>> <JTARecoveryService Name="Server2"/>
          >>>> </Server>
          >>>> <MigratableTarget Cluster="MyCluster" Name="Server1 (migratable)"
          >>>> Notes="This is a system generated default migratable target
          >>>
          >>>for a server.
          >>>
          >>>>Do not delete manually." UserPreferredServer="Server1"/>
          >>>> <MigratableTarget Cluster="MyCluster" Name="Server2 (migratable)"
          >>>> Notes="This is a system generated default migratable target
          >>>
          >>>for a server.
          >>>
          >>>>Do not delete manually." UserPreferredServer="Server2"/>
          >>>> <Application Deployed="true" Name="STARSII"
          >>>> Path="C:\cvsrepo\STARSII\STARSII" StagingMode="nostage" TwoPhase="true">
          >>>> <EJBComponent Name="../brsbMessage" Targets="MyCluster" URI="../brsbMessage"/>
          >>>> <EJBComponent Name="../brsbSession" Targets="MyCluster" URI="../brsbSession"/>
          >>>> <EJBComponent Name="../commonSession" Targets="MyCluster"
          >>
          >>URI="../commonSession"/>
          >>
          >>>> <EJBComponent Name="../complianceMessage" Targets="MyCluster"
          >>>
          >>>URI="../complianceMessage"/>
          >>>
          >>>> <EJBComponent Name="../complianceSession" Targets="MyCluster"
          >>>
          >>>URI="../complianceSession"/>
          >>>
          >>>> <EJBComponent Name="../starsiiEntity" Targets="MyCluster"
          >>
          >>URI="../starsiiEntity"/>
          >>
          >>>> <EJBComponent Name="../storeSession" Targets="MyCluster" URI="../storeSession"/>
          >>>> <WebAppComponent Name="/brsb" Targets="MyCluster" URI="../brsbWebApp"/>
          >>>> <WebAppComponent Name="/compliance" Targets="MyCluster" URI="../complianceWebApp"/>
          >>>> <WebAppComponent Name="/common" Targets="MyCluster" URI="../mainWebApp"/>
          >>>> <WebAppComponent Name="/store" Targets="MyCluster" URI="../storeWebApp"/>
          >>>> </Application>
          >>>> <Application Name="AffWebApp" Path="C:\cvsrepo\STARSII"
          >>>> StagingMode="nostage" TwoPhase="true">
          >>>> <WebAppComponent Name="AffWebApp" Targets="" URI="AffWebApp"/>
          >>>> </Application>
          >>>> <Application Name="activeportal"
          >>>> Path="C:\bea\user_projects\domains\mydomain\myserver\upload"
          >>>> StagingMode="nostage" TwoPhase="true">
          >>>> <WebAppComponent Name="activeportal" Targets="" URI="activeportal.war"/>
          >>>> </Application>
          >>>> <JTA Name="mydomain" TimeoutSeconds="300"/>
          >>>> <JMSServer Name="JobServer" Targets="Server1 (migratable)">
          >>>> <JMSQueue CreationTime="1072820642598"
          >>>> JNDIName="jms/STARSIIJobQueue" Name="STARSIIJobQueue"/>
          >>>> <JMSQueue CreationTime="1072820669345"
          >>>> JNDIName="jms/STARSIIPostQueue" Name="STARSIIPostQueue"/>
          >>>> <JMSQueue CreationTime="1088000795852"
          >>>> JNDIName="jms/STARSIIValidationQueue" Name="STARSIIValidationQueue"/>
          >>>> <JMSQueue CreationTime="1072820687125"
          >>>> JNDIName="jms/STARSIIErrorQueue" Name="STARSIIErrorQueue"/>
          >>>> <JMSQueue CreationTime="1072820687125"
          >>>> JNDIName="jms/STARSIIEmailQueue" Name="STARSIIEmailQueue"/>
          >>>> <JMSQueue CreationTime="1072820687225"
          >>>> JNDIName="jms/STARSIIEBTStateQueue" Name="STARSIIEBTStateQueue"/>
          >>>> <JMSQueue CreationTime="1072820687325"
          >>>> JNDIName="jms/STARSIIRFIQueue" Name="STARSIIRFIQueue"/>
          >>>> <JMSQueue CreationTime="1072820687425"
          >>>> JNDIName="jms/STARSIIRedeQueue" Name="STARSIIRedeQueue"/>
          >>>> <JMSQueue CreationTime="1072820687525"
          >>>> JNDIName="jms/STARSIIWatchListQueue" Name="STARIIWatchListQueue"/>
          >>>> <JMSQueue CreationTime="1072820687625"
          >>>> JNDIName="jms/STARSIIDeleteTransFileQueue" Name="STARSIIDeleteTransFileQueue"/>
          >>>> <JMSQueue CreationTime="1072820687725"
          >>>> JNDIName="jms/STARSIIUpdateAMRQueue" Name="STARSIIUpdateAMRQueue"/>
          >>>> <JMSQueue CreationTime="1072820687825"
          >>>> JNDIName="jms/STARSIIVPPExtractQueue" Name="STARSIIVPPExtractQueue"/>
          >>>> <JMSQueue CreationTime="1072820687925"
          >>>> JNDIName="jms/STARSIISIFSUploadQueue" Name="STARSIISIFSUploadQueue"/>
          >>>> <JMSQueue CreationTime="1072820688025"
          >>>> JNDIName="jms/STARSIIMARSQueue" Name="STARSIIMARSQueue"/>
          >>>> <JMSQueue CreationTime="1072820688125"
          >>>> JNDIName="jms/STARSIIFRBRichmondExtractQueue" Name="STARSIIFRBRichmondExtractQueue"/>
          >>>> <JMSQueue CreationTime="1072820688225"
          >>>> JNDIName="jms/STARSIICOTSExtractQueue" Name="STARSIICOTSExtractQueue"/>
          >>>> <JMSQueue CreationTime="1072820688325"
          >>>> JNDIName="jms/STARSIIVPPUploadQueue" Name="STARSIIVPPUploadQueue"/>
          >>>> </JMSServer>
          >>>> <Machine Name="MachineB">
          >>>> <NodeManager DebugEnabled="true" Name="MachineB"/>
          >>>> </Machine>
          >>>></Domain>
          >>>
          >

Ant to delete JMS Server

          I am trying to use an Ant script to configure a new domain for weblogic server
          8.1
          Ideally I want to run the script and have it configure all resources I will need
          (jdbc, jms, etc.). Currently I am having issues with the configuring of the JMS
          Server. I am using the following line of code to delete the JMS Server instance
          if it currently exist.
          <delete mbean="${domain.name}:Name=cgJMSServer,Type=JMSServer"/>
          This seems to be ignored by Ant because when I call the create task I get an InstanceAlreadyExist
          error. I assume my delete task is failing but giving no error. I'd like to be
          able to delete the current JMS server if one exist and then recreate it. I was
          wondering what the correct task or syntax would be for deleting the JMS server
          through Ant.
          Additionally, I'd like to use wlserver to create a new Integration Domain. I havent
          seen any documentation on how to specify a template to use when using the wlserver
          task, so I am not sure if this is possible or not.


Hi Allen,
          I think you may need to set the target of the JMS server
          to null first.
          I think the "JMSML" utility on dev2dev does this sort of
          task. You might want to take a look at its source to
          divine what steps it goes through.
          Tom
          Allan wrote:
          > I am trying to use an Ant script to configure a new domain for weblogic server
          > 8.1
          >
          > Ideally I want to run the script and have it configure all resources I will need
          > (jdbc, jms, etc.). Currently I am having issues with the configuring of the JMS
          > Server. I am using the following line of code to delete the JMS Server instance
          > if it currently exist.
          >
          > <delete mbean="${domain.name}:Name=cgJMSServer,Type=JMSServer"/>
          >
          > This seems to be ignored by Ant because when I call the create task I get an InstanceAlreadyExist
          > error. I assume my delete task is failing but giving no error. I'd like to be
          > able to delete the current JMS server if one exist and then recreate it. I was
          > wondering what the correct task or syntax would be for deleting the JMS server
          > through Ant.
          >
          > Additionally, I'd like to use wlserver to create a new Integration Domain. I havent
          > seen any documentation on how to specify a template to use when using the wlserver
          > task, so I am not sure if this is possible or not.

Can JMS topics and queues be clustered in a WLS 7.0 Cluster?

We are installing a weblogic 7.0 cluster with 1 admin server and 2 managed
          node servers. Two nodes have been clustered. We are at the point where we
          need to configure JMS. Has any one implemented JMS in WLS 7 clustered
          environment? What are the things to watch out when clustering JMS? Can JMS
          topics and queues be clustered?
          TIA for any helpful hints and comments.
          Regards


"Karim Ali" <[email protected]> wrote:
          >> Has any one implemented JMS in WLS 7 clustered
          >> environment?
          I'm currently working on a project with WLS 7 here at work, involving
          the implementation of BEA's JMS Cluster. So far, I really haven't had
          many hiccups.
          "Karim Ali" <[email protected]> wrote:
          >> What are the things to watch out when clustering JMS?
          At least in WLS 7, the biggest thing that stands out is the lack of
          automatic failover. Also, Message Paging -- make sure you configure
          paging high/low thresholds. Or, if you don't wish for it to occur but
          can't stop the server (very common these days with SLAs), set that
          byte/message high threshold to a very large number (correct me if I'm
          wrong, but I believe BEA recommends 2^63 -1).
          "Karim Ali" <[email protected]> wrote:
          >> Can JMS topics and queues be clustered?
          Well, since Topics and Queues are extensions of the
          javax.jms.Destination interface, the answer is: Yes!
          (SIDE NOTE: most people usually refer to them as a [JMS] "destination"
          -- it avoids a lot of conceptual baggage and plus, less typing!)
          You'll probably want to see this section of BEA's e-docs:
          http://edocs.bea.com/wls/docs70/adminguide/jms.html#config_distributed_destinations
          later,
          Brian J. Mitchell
          BEA Systems Administrator
          TRX
          Atlanta, GA
          email: [email protected]
          office: 404-327-7238
          mobile: 678-283-6530

JMS server targeted to several clusters

Similar Messages

Maybe you are looking for