Help!! Configuring JMS in WebLogic (w/cluster & managed servers) to deploy a Workshop Portal app

Posted on 2006-07-03
Last Modified: 2013-12-10

I am trying to setup a test environment.

The target configuration consists of 2 physical machines, each with WebLogic 8.1 SP3.

I also have a 3rd machine with WebLogic that I use Workshop to create a portal app (portal.ear).

On the first target machine, "weblogic", I have configured an admin server.  On second target machine, I have a cluster ("mycluster") with two managed servers ("myman1" and "myman2").

I've been successful at getting this configuration working, where I can start/stop the managed servers in the cluster using the WebLogic console on the 1st machine, and I am able to deploy my portal app to both the admin server and to the cluster.

BUT, I am having a problem where I am seeing warnings in the managed server logs like:

####<Jul 3, 2006 10:11:07 PM EDT> <Warning> <EJB> <weblogiccluster> <myman1> <ExecuteThread: '13' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-010096> <The Message-Driven EJB: KNEX.bean.QueueTransport is unable to connect to the JMS destination: jws.queue. Connection failed after 2 attempts. The MDB will attempt to reconnect every 10 seconds. This log message will repeat every 600 seconds until the condition clears.>
####<Jul 3, 2006 10:11:07 PM EDT> <Warning> <EJB> <weblogiccluster> <myman1> <ExecuteThread: '13' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <> <BEA-010061> <The Message-Driven EJB: KNEX.bean.QueueTransport is unable to connect to the JMS destination: jws.queue_auto_1. The Error was:
[EJB:011010]The JMS destination with the JNDI name: jws.queue_auto_1 could not be found. Please ensure that the JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination has been deployed.>

And then, the DefaultAuditRecorder.log file gets filled up VERY quickly, growing to over 1/2 GB for each managed server until eventually the entire hard drive is full, then everything comes to a grinding halt :(!!

When I look in WebLogic console, it LOOKS like I've created the jws.queue and jws.queue_auto_1 (and jws.queue_auto_2)), and I've targeted jsw.queue_auto_1 to "myman1", and jsw.queue_auto_2 to "myman2".  The "jws.queue" is configured as a Distributed Destination which is auto deployed to myman1 and myman2.

So, I CANNOT understand why the KNEX.bean.QueueTransport on myman1 "can't connect" to jws.queue_auto_1??  Same situation on myman2, for jws.queue_auto_2.

Can anyone please help me?  

I'm really new to WebLogic environment, and I know that I *MUST* be missing something, probably something really obvious, and I've read a lot of stuff on BEA's website and also a pile of WebLogic books, but can't figure out what :(!!

Since I'm fairly unfamiliar with WebLogic, if you know what I need to do, please describe it specifically, and I'd prefer not to be pointed back to something on BEA's website, as I've scoured that pretty thoroughly, and most of it is "over my head"...

Thanks in advance,
Question by:jimcpl
  • 3
  • 2
LVL 35

Expert Comment

ID: 17036991
Hi jimcpl

Can you make sure that you have connectivity between the two machines that your two managed servers are running? It seems liek the jms queue is deployed on one machine but the other machine tries to reach it and it cannot.


Author Comment

ID: 17038573

The two "machines" are actually two VM guest hosts on the same physical machine, and yes, there's connectivity.

You mentioned that "the jms queue is deployed", and a lot of the material I've read mentions "deploy".  How EXACTLY do you "deploy" the JMS queue?  Is it the dropdown box when you click on <jms server> and then click on the "Target and Deploy" button?

If so, that dropdown box seems to only allow to select ONE server?  Is that right?

Also, in my case, there's a "myman1" and "myman1 (migratable)".  What is the "migratable"?

Finally, I am seeing errors on BOTH managed server logs where it says it can't find the same JMS queue (jws.queue).  How can that be, since, from what I've read, a JMS queue can only be designated/targeted to a SINGLE server?

Sorry about all the questions, but this is all a little overwhelming...

LVL 35

Expert Comment

ID: 17038659
> Is it the dropdown box when you click on <jms server> and then click on the "Target and Deploy"

Yes, although there are other ways to deploy it also (silent deploy etc), but it is out of the scope of this question atm.

> If so, that dropdown box seems to only allow to select ONE server?  Is that right?

Yes this is right, it should be deployed into one server (this is a pinned service) and in case of failover it should be migrated to the other instance of wls. This job is left to the cluster.

> Also, in my case, there's a "myman1" and "myman1 (migratable)".  What is the "migratable"?

Look at my comment above. What is going on is that the JMS queue is deployed into *one* server instance (this is done to avoid messages being sent to all instances of wls running in the cluster). All messages from all servers go to that queue on this one server. If this server fails then this queue is migrated (copied) into another server instance. This is what"migratale" means.

> How can that be, since, from what I've read, a JMS queue can only be designated/targeted to a SINGLE server?

When managed servers start they try to communicate with all the services deployed in the cluster (jms queues, datasources, JTA ,etc) in order to see if they are up and running. It does not matter if the jms queue is only targeted to one server, all the servers in the cluster will try to establish communication on order to see if things are fine.

Have a look here for pinned services and how they are migrated:

Ok, back to the problem again, can you check from your console if you have these queues defined? You can do that from JMS Servers -> "your server" -> JMS Destinations and tell me what you see?
NAS Cloud Backup Strategies

This article explains backup scenarios when using network storage. We review the so-called “3-2-1 strategy” and summarize the methods you can use to send NAS data to the cloud


Author Comment

ID: 17038842

Thanks for the explanations.  I'll try to answer your last question, and then followup on what you said.

I have (JMS server name / destination JNDI name / target):

cgJMSServer_auto_1 / jws.queue_auto_1 / myman1
cgJMSServer_auto_2 / jws.queue_auto_2 / myman2
MyJMS Server / app.queue.AsyncDispatcher / portalServer (this is my admin server)
                     / app.queue.AsyncDispatcher_error / portalServer

I looked around for JNDI name "jws.queue", and that is configured under a "Distributed Destination" named "dist_cgJWSQueue_auto".  This has "Auto Deploy" set to "myman1" and "myman2".

Even with the above, I am STILL getting msgs on myman1 and myman2 log files saying that it can't find "jws.queue" and "app.queue.Dispatcher"??

Now for my followup to your comments:

1) So, the machine that I deploy the JMS server to doesn't matter?  What I mean by this, is that if I targeted all of the JMS servers above to "myman1", then "myman2" should still be able to find and connect to all of the JMS queues?

2) Also, what about portalServer?  If I target all the JMS servers to, say, "myman1", would portalServer be able to find/connect to all of those JMS queues/destinations?

3) Same as #2, but vice-versa, i.e., if I target all of the JMS servers to portalServer, would all of the managed servers be able to find/connect to all of those JMS queues/destinations?

I just found out about viewing the individual server JNDI tree by right clicking on the server.

Using that:

On portalServer:
I see app.queue.AsyncDispatcher and app.queue.AsyncDispatcher_error, but none of the jws.* names.

On myman1:
I see jws.queue, jws.queue_auto_1, and jws.queue_auto_2, but not app.queue.*

On myman2:
I see jws.queue, jws.queue_auto_1, and jws.queue_auto_2, but not app.queue.*

I guess I'm also confused about what this "JNDI tree" is showing?  Is it showing the JNDI names that are available "FROM" a server on that machine?

Thanks again,

LVL 35

Accepted Solution

girionis earned 250 total points
ID: 17049247
Hi Jim

1) Yes it does not matter, since the JNDI of the JMS queue should be replicated to all managed servers (there is an option in JMS destinations "Replicate JNDI Name In Cluster"). When a request comes to a managed server that does not have the jms queue then it will find the queue from the jndi name and will send the request there.

2) and 3) PortalServer is your admin server. Admin servers should not do any applciation specific tasks, they should only manage the managed servers. It is not a good idea to deploy applications on the admin server.

As a side note, the jws.<something> are the jndi names that WLS supports by default. In general it is not a good idea to sue these jndi and access the default queue, better create your own queues and your own jndi names.

Can you try creating your own JMS with your own JNDI and see if that helps?
LVL 23

Assisted Solution

rama_krishna580 earned 250 total points
ID: 17075259

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Replication has always been one of those technologies that people run scared from. The main reason is usually cost. When you think of replication, your mind drifts to solutions that replicate from one disk frame to another using block level technolo…
The Delta outage: 650 cancelled flights, more than 1200 delayed flights, thousands of frustrated customers, tens of millions of dollars in damages – plus untold reputational damage to one of the world’s most trusted airlines. All due to a catastroph…
This tutorial will walk an individual through locating and launching the BEUtility application to properly change the service account username and\or password in situation where it may be necessary or where the password has been inadvertently change…
This tutorial will show how to configure a single USB drive with a separate folder for each day of the week. This will allow each of the backups to be kept separate preventing the previous day’s backup from being overwritten. The USB drive must be s…

948 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now