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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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?
The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in 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

Get 15 Days FREE Full-Featured Trial

Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users

Question has a verified solution.

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

In this article we will learn how to backup a VMware farm using Nakivo Backup & Replication. In this tutorial we will install the software on a Windows 2012 R2 Server.
This article shows how to use a free utility called 'Parkdale' to easily test the performance and benchmark any Hard Drive(s) installed in your computer. We also look at RAM Disks and their speed comparisons.
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…

626 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