Expiring Today—Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


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

Posted on 2006-07-03
Medium Priority
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: http://e-docs.bea.com/wls/docs81/cluster/setup.html#726721

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?
Building an interactive eFuture classroom

Watch and learn how ATEN provided a total control system solution including seamless switching matrix switch, HDBaseT extenders, PDU, lighting control to build an interactive eFuture classroom.


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 1000 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 1000 total points
ID: 17075259

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

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

The article will include the best Data Recovery Tools along with their Features, Capabilities, and their Download Links. Hope you’ll enjoy it and will choose the one as required by you.
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…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

718 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