Solved

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

Posted on 2006-07-03
8
3,502 Views
Last Modified: 2013-12-10
Hi,

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,
Jim
0
Comment
Question by:jimcpl
  • 3
  • 2
8 Comments
 
LVL 35

Expert Comment

by:girionis
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.

Cheers
0
 
LVL 1

Author Comment

by:jimcpl
ID: 17038573
girionis,

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...

Jim
0
 
LVL 35

Expert Comment

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

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?
0
How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

 
LVL 1

Author Comment

by:jimcpl
ID: 17038842
girionis,

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,
Jim

0
 
LVL 35

Accepted Solution

by:
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?
0
 
LVL 23

Assisted Solution

by:rama_krishna580
rama_krishna580 earned 250 total points
ID: 17075259
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

A Bare Metal Image backup allows for the restore of an entire system to a similar or dissimilar hardware. They are highly useful for migrations and disaster recovery. Bare Metal Image backups support Full and Incremental backups. Differential backup…
Workplace bullying has increased with the use of email and social media. Retain evidence of this with email archiving to protect your employees.
To efficiently enable the rotation of USB drives for backups, storage pools need to be created. This way no matter which USB drive is installed, the backups will successfully write without any administrative intervention. Multiple USB devices need t…
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…

743 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

11 Experts available now in Live!

Get 1:1 Help Now