Posts Tagged ‘Weblogic 10’

Case and Topology

RMI services are deployed on UAT, exposed via a F5, at the following address: t3://my-f5-frontal.my.domain.extension:7090
The actual servers are my-first-node.my.domain.extension and my-second-node.my.domain.extension.

The client application is deployed in a remote location, on a QA server.
The ports are open between QA and UAT, and we can ping and use telnet with no issue on QA.

Anyway, when I launch the client application from QA, I get the following error:

[java]2011-10-31 06:41:03,277 INFO support.DefaultListableBeanFactory – Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@79e304: defining beans [jonathanServiceClient]; root of factory hierarchy
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘smartServiceClient’ defined in class path resource [com/lalou/jonathan/rmi-client-spring.xml]: Invocation of init method failed; nested exception is org.springframework.remoting.RemoteLookupFailureException: JNDI lookup for RMI service [rmiServices] failed; nested exception is javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://my-f5-frontal.my.domain.extension:7090: Bootstrap to my-f5-frontal.my.domain.extension/111.222.012.123:7090 failed. It is likely that the remote side declared peer gone on this JVM][/java]

Explanation and Fix

Owing to my understanding, here is the point: when the client tries to connect to F5, it presents itself with its name, and the F5 returns the name of the actual server. If both client and server are not on the same domain (“domain” as network domain, no link with Weblogic domain), then the DNS resolution may fail.

To fix this issue, you have to follow one or both of the following points: everything depends on your local topology.

WebLogic: “Listen Address”

Modify the “Listen Address” in WebLogic administration console, from home:  Servers > MyFirstNode/MySecondNode > Configuration > General > Listen Address > update it

By “update” the “Listen Address”, I mean providing the complete name of the machines, including the domain extension.
eg: my-first-node.my.domain.extension and my-second-node.my.domain.extension, rather than my-first-node and my-second-node (or, even worse, localhost).
You can also provide an IP, cf. WebLogic documentation on Oracle’s website.

Of course, you can decide to set it directly in WebLogic’s config.xml.

Caution! This option may also be set via the command line running WebLogic, using the flag -Dweblogic.ListenAddress=... Therefore, take care to be consistent between the content of console/config.xml and the command line option.

Hosts

On client side, check the content of hosts file. Usually, you can found it at /etc/hosts (or C:\WINDOWS\system32\drivers\etc\hosts on Windows XP).
Assuming your machine is myClientMachine with an IP 123.123.123.123 and a domain extension remote.domain, then your hosts file should look like:

[java]127.0.0.1 localhost
123.123.123.123 myClientMachine[/java]

Update it to:

[java]127.0.0.1 localhost
123.123.123.123 myClientMachine myClientMachine.remote.domain[/java]

Abstract

The application I work on packages Mule ESB 2.2.1 in a WAR and deploys it under a WebLogic 10.3 server. My team mates and I noticed that, on multiple deploy/undeploy cycles, the PermGen size dramatically decreased. The cause of this was the number of threads, which hardly decreased on undeployment phases, unlike the expected behaviour.
Indeed, Mule is seldom deployed as a WebApp. Rather, it is designed to be run as a standalone application, within a Tanuki wrapper. When the JVM is killed, all the threads are killed, too, and therefore no thread survives ; hence, the memory is freed and there is no reason to fear a thread leak.

Moreover, when the application is redeployed, new threads -with the same names as the “old” threads- are created. The risk is that, for any reason, a thread-name-based communication between threads may fail, because the communication pipe may be read by the wrong thread.

In my case: on WebLogic startup, there are 31 threads ; when the application is deployed, there are 150 ; when the application works (receives and handles messages), the number of threads climbs to 800 ; when the application is undeployed, only 12 threads are killed, the other remaining alive.

The question is: how to kill Mule-created threads, in order to avoid a Thread leak?

WebLogic Threads

I performed a thread dump at WebLogic startup. Here are WebLogic threads, created before any deployment occurs:

[java]Attach Listener
DoSManager
DynamicListenThread[Default[1]]
DynamicListenThread[Default]
ExecuteThread: ‘0’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘1’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’
Finalizer
JMX server connection timeout 42
RMI Scheduler(0)
RMI TCP Accept-0
RMI TCP Connection(1)-127.0.0.1
RMI TCP Connection(2)-127.0.0.1
Reference Handler
Signal Dispatcher
Thread-10
Thread-11
Timer-0
Timer-1
VDE Transaction Processor Thread
[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[ACTIVE] ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘5’ for queue: ‘weblogic.kernel.Default (self-tuning)’
main
weblogic.GCMonitor
weblogic.cluster.MessageReceiver
weblogic.time.TimeEventGenerator
weblogic.timers.TimerThread
[/java]

Dispose Disposables, Stop Stoppables…

The application being deployed in a WAR, I created a servlet implementing ServletContextListener. In the method contextDestroyed(), I destroy Mule objects (Disposable, Stoppable, Model, Service, etc.) one per one.
Eg#1:

[java] final Collection<Model> allModels;
try {
allModels = MuleServer.getMuleContext().getRegistry().lookupObjects(Model.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Disposing models " + allModels.size());
}
for (Model model : allModels) {
model.dispose();
}
allModels.clear();
} catch (Exception e) {
LOGGER.error(e);
}[/java]

Eg#2:

[java] private void stopStoppables() {
final Collection<Stoppable> allStoppables;
try {
allStoppables = MuleServer.getMuleContext().getRegistry().lookupObjects(Stoppable.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Stopping stoppables " + allStoppables.size());
}
for (Stoppable stoppable : allStoppables) {
stoppable.stop();
}
allStoppables.clear();
} catch (MuleException e) {
LOGGER.error(e);
}
}[/java]

This first step is needed because default mechanism is flawed: Mule re-creates objects that were destroyed.

Kill Threads

The general idea to kill Mule threads is the following: perform a Unix-style “diff” between WebLogic native threads, and the threads still alive once all Mule objects have been stopped and disposed.

On Application Startup

In the ServletContextListener, I add a field that will be set in a method called in the constructor:
[java] private List<String> threadsAtStartup;
(…)
/**
* This method retrieves the Threads present at startup: mainly speaking, they are Threads related to WebLogic.
*/
private void retrieveThreadsOnStartup() {
final Thread[] threads;
final ThreadGroup threadGroup;
threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
} catch (IllegalAccessException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
}

threadsAtStartup = new ArrayList<String>(threads.length);
for (int i = 0; i < threads.length; i++) {
final Thread thread;
try {
thread = threads[i];
if (null != thread) {
threadsAtStartup.add(thread.getName());
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("This Thread was available at startup: " + thread.getName());
}
}
} catch (RuntimeException e) {
LOGGER.error("An error occured on initial Thread statement: ", e);
}
}
}
/**
* Hack to retrieve the field ThreadGroup.threads, which is package-protected and therefore not accessible
*
* @param threadGroup
* @return
* @throws NoSuchFieldException
* @throws IllegalAccessException
*/
private Thread[] retrieveCurrentActiveThreads(ThreadGroup threadGroup) throws NoSuchFieldException, IllegalAccessException {
final Thread[] threads;
final Field privateThreadsField;
privateThreadsField = ThreadGroup.class.getDeclaredField("threads");
privateThreadsField.setAccessible(true);

threads = (Thread[]) privateThreadsField.get(threadGroup);
return threads;
}
[/java]

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:
[java] /**
* Cleanses the Threads on shutdown: theorically, when the WebApp is undeployed, should remain only the threads
* that were present before the WAR was deployed. Unfornately, Mule leaves alive many threads on shutdown, reducing
* PermGen size and recreating new threads with the same names as the old ones, inducing a kind of instability.
*/
private void cleanseThreadsOnShutdown() {
final Thread[] threads;
final ThreadGroup threadGroup;
final String currentThreadName;

currentThreadName = Thread.currentThread().getName();

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("On shutdown, currentThreadName is: " + currentThreadName);
}

threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
} catch (IllegalAccessException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
}

for (Thread thread : threads) {
final String threadName = thread.getName();
final Boolean shouldThisThreadBeKilled;

shouldThisThreadBeKilled = isThisThreadToBeKilled(currentThreadName, threadName);
if (LOGGER.isDebugEnabled()) {
LOGGER.info("should the thread named " + threadName + " be killed? " + shouldThisThreadBeKilled);
}
if (shouldThisThreadBeKilled) {
thread.interrupt();
thread = null;
}
}

}

/**
* Says whether a thread is to be killed<br/>
* Rules:
* <ul><li>a Thread must NOT be killed if:</li>
* <ol>
* <li>it was among the threads available at startup</li>
* <li>it is a Thread belonging to WebLogic (normally, WebLogic threads are among the list in the previous case</li>
* <li>it is the current Thread (simple protection against unlikely situation)</li>
* </ol>
* <li>a Thread must be killed: in all other cases</li>
* </ul>
*
* @param currentThreadName
* @param threadName
* @return
*/
private Boolean isThisThreadToBeKilled(String currentThreadName, String threadName) {
final Boolean toBeKilled;
toBeKilled = !threadsAtStartup.contains(threadName)
&amp;&amp; !StringUtils.contains(threadName, "weblogic")
&amp;&amp; !threadName.equalsIgnoreCase(currentThreadName);
return toBeKilled;
}
[/java]

EhCache

My application uses an EhCache. Its threads names usually end with “.data”. They are not killed by the previous actions. To get rid of them, the most elegant way is to add this block in the web.xml:
[xml] <listener>
<listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
</listener>
[/xml]
cf EhCache documentation

With all these operations, almost all threads are killed. But Java VisualVM still displays 34, vs. 31 at startup.

Tough Threads

A thread dump confirms that, at this point, 3 rebellious threads still refuse to be kill:
[java]MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1
[/java]
Let’s examine them:

• MuleServer.1: This thread is an instance of the inner class MuleServer.ShutdownThread. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before the ServletContextListener is called… I did not succeed in killing it, even why trying to kill it namely, which makes sense: killing the father thread looks like suiciding the ServletContextListener.
• SocketTimeoutMonitor-Monitor.1: This thread is created by Mule’s TcpConnector and its daughter classes: HttpConnector, SslConnector, etc. Again, I could not kill them.

Conclusion

We have seen Mule suffers of major thread leaks when deployed as a WAR. Anyway, most of these leaks may be sealed.
I assume MuleSoft was aware of this issue: in the version 3 of Mule, the deployment of webapps was refactored.

Case

I introduced an Oracle Coherence cache withing my application, which is deployed as a WAR within WebLogic  Server. In a first step, I used an instance of Oracle Coherence / Coherence Web already built in WebLogic. Then, for a couple a reasons, I detroyed the Coherence cluster. Deploying the application, the following error appeared:

[java]java.lang.RuntimeException: Failed to start Service "Cluster" (ServiceState=SERVICE_STOPPED, STATE_ANNOUNCE)[/java]

Complete Stacktrace

[java]java.lang.RuntimeException: Failed to start Service "Cluster" (ServiceState=SERVICE_STOPPED, STATE_ANNOUNCE)
at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.start(Service.CDB:38)
at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Grid.start(Grid.CDB:38)
at com.tangosol.coherence.component.net.Cluster.onStart(Cluster.CDB:366)
at com.tangosol.coherence.component.net.Cluster.start(Cluster.CDB:11)
at com.tangosol.coherence.component.util.SafeCluster.startCluster(SafeCluster.CDB:3)[/java]

Explanation and Fix

The Coherence cluster view available in WebLogic server is a view of the Tangosol configuration, available in the files tangosol-coherence*.xml of Coherence’s JAR. To fix the issue, create a file tangosol-coherence-override.xml, in your classpath. Fill the file with a minimum content, such as:

[xml]<?xml version=’1.0′?>
<!DOCTYPE coherence SYSTEM "coherence.dtd">
<coherence>
<cluster-config>
<multicast-listener>
<time-to-live system-property="tangosol.coherence.ttl">0</time-to-live>
<join-timeout-milliseconds>3000</join-timeout-milliseconds>
</multicast-listener>
<unicast-listener>
<address>127.0.0.1</address>
<port>8088</port>
<port-auto-adjust>true</port-auto-adjust>
<priority>8</priority>
</unicast-listener>
<packet-publisher>
<packet-delivery>
<timeout-milliseconds>30000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
<service-guardian>
<timeout-milliseconds system-property="tangosol.coherence.guard.timeout">35000</timeout-milliseconds>
</service-guardian>
</cluster-config>
<logging-config>
<severity-level system-property="tangosol.coherence.log.level">5</severity-level>
<character-limit system-property="tangosol.coherence.log.limit">0</character-limit>
</logging-config>
</coherence>
[/xml]

Of course, you can amend and improve the file to match your requirements.
NB: in case your file is ignored by Coherence, override the property tangosol.coherence.override with value tangosol-coherence-override.xml.

Case

You would like to set a System property within an application packaged as a WAR.
Of course, you may modify the launching scripts of your servers, to add an option -DmyPropertyName=myPropertyValue. Sometimes, you would like to avoid such a solution, because updating the property would require an update of the setEnv.* files and therefore a action of the exploitation team.

In my case, I had to set the property tangosol.coherence.cacheconfig, which hints at the configuration file used my Oracle Coherence / Coherence*Web

Fix

The first solution is to set the property in a startup class. For more detials, consult this page: WebLogic: use a startup and/or a shutdown class in a WAR.

Another mean to handle this problematic is to create a servlet, with a code similar to:

[java]public class JonathanBootServlet extends HttpServlet {
private static final Logger LOGGER = Logger.getLogger(JonathanBootServlet.class);
private static final String SVN_ID = "$Id$";

public JonathanBootServlet() {
super();
if (LOGGER.isDebugEnabled()){
LOGGER.debug(SVN_ID);
}
}

public void init(ServletConfig config) throws ServletException {
if (LOGGER.isDebugEnabled()){
LOGGER.debug("in init()");
}
System.setProperty("tangosol.coherence.cacheconfig", "jonathan-tangosol-coherence.xml");
super.init(config);
}
}[/java]

Then add the following block in your web.xml:

[xml] <servlet>
<servlet-name>JonathanBootServlet</servlet-name>
<servlet-class>lalou.jonathan.weblogic.technical.JonathanBootServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>[/xml]

Ensure this servlet is run before all others (1).

Case

You have an application which uses Oracle Coherence / Coherence*Web as cache manager. On redeploying the application, you get a stacktrace of which header is:

[java]Exception in thread ‘DistributedCache|SERVICE_STOPPED’ java.lang.NoClassDefFoundError: com/tangosol/run/component/EventDeathException[/java]

Explanation

Indeed, an undeploy operation stops the services of your application. But Coherence is not launched as a service among the others: it should be considered as an independant one. Therefore, you have to stop it before undeploying your application ; otherwise, your classloader is in a confused state, and loses references to classes it had loaded before, but that should now be unloaded.

Fix

You have to stop Oracle Coherence on your application shutdown.

EAR

If your application is packaged as an EAR, then create a shutdown class with the following main():

[java]public class JonathanLalouEARShutdown extends ApplicationLifecycleListener {
public static void main(String[] args) {
CacheFactory.shutdown();
}
}[/java]

Add the following block in your weblogic-application.xml, hinting the shutdown class:

[xml]<shutdown>
<shutdown-class>lalou.jonathan.weblogic.JonathanLalouEARShutdown </shutdown-class>
</shutdown>[/xml]

WAR

If your application is packaged as a WAR, then create a class implementing ServletContextListener, and add the following block in your web.xml:

[xml]
<listener>
<listener-class>your.class.implementing.ServletContextListener</listener-class>
</listener>
[/xml]

The detailed procedure is described at this link: WebLogic: use a startup and/or a shutdown class in a WAR

Abstract

WebLogic offers you to specify a startup and/or a shutdown class for an application. Anyway, this feature is restrained to EARs, and is not available for applications deployed as WARs. For EARs, Oracle WebLogic Server’s documentation is complete and gives basic examples: Programming Application Life Cycle Events

Yet, sometimes you need such a class even for a WebApp. You have two ways to handle this case.

Solutions

Full Weblogic!

Base

The first solution is not elegant. Open WebLogic console, go to Startup And Shutdown Classes, then add the classes names of which main() methods will be run on startup and shutdown, let’s say JonathanWeblogicStartup. These classes must be available in WebLogic classpath, which is surely different from your application classpath, eg in a library $DOMAIN_HOME/lib/customized-weblogic.jar.
Advantage of this means: if your startup/shutdown class does not evoluate often, then write it once and forget, it will be OK. Unlike, you will have to manage different versions of the JAR on each release… I assume your exploitation team may get angry at playing with classpaths and lib folders 😀

Suggestion

To improve the basic solution (and avoid your exploitation guy burst in your office), I had the following idea, that I did not experiment, but that should work:

• Keep JonathanWeblogicStartup

• Create another class JonathanConcreteStartup, locate as a source in your application code.
• In JonathanStartup.main(), call JonathanConcreteStartup

This way,

1. You keep a unique JAR in classpath that you do not need to update and you can forget.
2. You can add, update or remove features in your very source code.
3. The exploitation teams does not become hateful at you.

Add a Listener

The second one requires a bit more work.

• Create a class implementing javax.servlet.ServletContextListener interface, let’s say MyLifecycleListener.
• Implement methods contextInitialized() and contextDestroyed().
• Edit your web.xml, add the following block:
  [xml]
  <listener>
  <listener-class>lalou.jonathan.MyLifecycleListener</listener-class>
  </listener>[/xml]
• Rebuild and deploy. It should be OK

Case

I have to integrate Oracle Coherence, or more accurately Coherence*Web, within an application deployed as a WAR in WebLogic 10.3.
Since Oracle bought both BEA and Tangosol, increasing their integration, using Coherence jars implicitely is allowed. Anyway I decided to add the following block in weblogic.xml

[xml] <library-ref>
<library-name>coherence-web-spi</library-name>
<specification-version>1.0.0.0</specification-version>
<implementation-version>1.0.0.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>
[/xml]

Then I get this error:

[java]Caused By: weblogic.management.DeploymentException: Error: Unresolved Webapp Library references for
""ServletContext@25681165[app:risklayer-web module:jonathan-lalou.war path:/jonathan-lalou spec-version:null]"", defined in weblogic.xml [Extension-Name: coherence-web-spi, Specification-Version: 1, Implementation-Version: 1.0.0.0, exact-match: false][/java]

Fix

Indeed, I had to deploy Coherence*Web WAR in WebLogic, in the console:
Deployments > Install > select Coherence WAR, eg: C:\jonathan\bea\coherence_3.5\lib\coherence-web-spi.war > Next> Install this deployment as a library > Next > Target your server > Finish

Case

In a Mule ESB workflow, the endpoint is a <jms:outbound-endpoint>, pointing to a JMS queue hosted on MQ Series and accessed through WebLogic 10.3.3.

I get the following stracktrace

[java]Exception stack is:
1. MQJE001: Completion Code 2, Reason 2027 (com.ibm.mq.MQException)
com.ibm.mq.MQQueue:1624 (null)
2. MQJMS2007: failed to send message to MQ queue(JMS Code: MQJMS2007) (javax.jms.JMSException)
com.ibm.mq.jms.services.ConfigEnvironment:622 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/JMSException.html)
3. Failed to create and dispatch response event over Jms destination "queue://MQSERVER/AMQ.4C8A5E112285475605?persistence=1". Failed to route event via endpoint: null. Message payload is of type: JMSObjectMessage (org.mule.api.transport.DispatchException)
org.mule.transport.jms.JmsReplyToHandler:154 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/transport/DispatchException.html)[/java]

Fix

On Mule config file, explicitly set the attribute disableTemporaryReplyToDestinations at true in the JMS outbound tag:

[xml]<jms:outbound-endpoint
queue="jonathan.lalou.jms.queue"
connector-ref="jmsConnector"
transformer-refs="foo" disableTemporaryReplyToDestinations="true"/>[/xml]

Abstract

You have a non-clustered installation, on the host with DNS name jonathanDevDesktop, with an admin (port: 7001), a muletier (port: 7003) and a webtier (port: 7005) instances.
You need set your muletier as a clustered installation, with two nodes, on the same server. The second node will dedeployed on port 7007.

We assume you have a configured JMS Modules (in our case: JmsMqModule, even though the bridge between WebLogic and MQ has no impact here).

Process

Batches

• Copy $DOMAINS\jonathanApplication\start-muletier-server.bat" as $DOMAINS\jonathanApplication\start-muletier-server-2.bat"
• Edit it:
  • Possibly, modify the debug port (usually: 5006)
  • Replace the line

    call "%DOMAIN_HOME%\bin\startManagedWebLogic.cmd" muletier t3://jonathanDevDesktop:7001

    with

    call "%DOMAIN_HOME%\bin\startManagedWebLogic.cmd" muletier2 t3://jonathanDevDesktop:7001

Second Node Creation

• Following points are not required.
  • Copy the folder %DOMAIN_HOME%\servers\muletier as %DOMAIN_HOME%\servers\muletier2
  • Delete the folders %DOMAIN_HOME%\servers\muletier2\cache and %DOMAIN_HOME%\servers\muletier2\logs
• Stop the server muletier
• On WebLogic console:
  • Servers > New > Server Name: muletier2, Server Listen Port: 7007 > Check Yes, create a new cluster for this server. > Next
  • Name: jonathanApplication.cluster.muletier > Messaging Mode: Multicast, Multicast Address: 239.235.0.4, Multicast Port:5777
  • Clusters > jonathanApplication.cluster.muletier > Configuration > Servers > Select a server: muletier
  • Clusters > jonathanApplication.cluster.muletier > Configuration > Servers > Select a server: muletier2
• Start the instances of muletier and muletier2 in MS-DOS consoles.
• On the WebLogic console:
  • Deployments > jonathanApplication-web (the mule instance) > Targets > check “jonathanApplication.cluster.muletier” and “All servers in the cluster” > Save
• On the muletier2 DOS console, you can see the application is deployed.

JMS Configuration

The deployment of JMS on clustered environment is a little tricky.

• On WebLogic console: JMS Modules > JmsMqModule > Targets > check “jonathanApplication.cluster.muletier” and “All servers in the cluster“
• Even though it is not required, restart your muletiers. Then you can send messages either on port 7003 or 7007, they will be popped and handled the same way.

Abstract

You have an application deployed on WebLogic 10 (used version for this tutorial: 10.3.3). You have to use an external provider for JMS, in our case MQ Series / WebSphere MQ.
The client side is a Mule ESB launched in standalone.

Prerequisites

You have:

• a running WebLogic 10 with an admin instance and an another instance, in our case: Muletier.
• a file file.bindings, used for MQ.

JARs installation

• Stop all your WebLogic 10 running instances.
• Get the JARs from MQ Series folders:
  • providerutil.jar
  • fscontext.jar
  • dhbcore.jar
  • connector.jar
  • commonservices.jar
  • com.ibm.mqjms.jar
  • com.ibm.mq.jar
• Copy them in your domain additional libraries folder (usually: user_projects/domains/jonathanApplication/lib/)
• Start WebLogic 10 admin. A block like this should appear:
  [java]&lt;Oct 15, 2010 12:09:21 PM CEST&gt; &lt;Notice&gt; &lt;WebLogicServer&gt; &lt;BEA-000395&gt; &lt;Following extensions directory contents added to the end of the classpath:
  C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mq.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mqjms.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\commonservices.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\connector.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\dhbcore.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\fscontext.jar;C:\win32app\bea\
  user_projects\domains\jonathanApplication\lib\providerutil.jar&gt;[/java]

Config

• Get file.bindings, copy it into user_projects/domains/jonathanApplication/config/jms, rename it as .bindings (without any prefix)
• Launch the console, login
• JMS > JMS Modules > Create JMS System Module > Name: JmsMqModule. Leave other fields empty. > Next > target server MuleTier > Finish
• Select JmsMqModule > New > Foreign Server > Name: MQForeignServer > keep check MuleTier > Finish
  • Select MQForeignServer >
    • JNDI Initial Context Factory: replace weblogic.jndi.WLInitialContextFactory with: com.sun.jndi.fscontext.RefFSContextFactory
    • JNDI Connection URL: set the URI of the folder containing the .bindings file, eg: file://c/win32app/bea/user_projects/domains/jonathanApplication/config/jms
  • Tab Connection Factories > New >
    • Name: MQForeignConnectionFactory
    • Local JNDI Name: the JNDI name on WebLogic side, eg: jonathanApplication/jms/connectionFactory/local (convention I could observe: separator on WebLogic: slash '/' ; unlike clients for which the separator in a dot '.')
    • Remote JNDI Name: the JNDI name on MQ side, eg: JONATHAN_APPLICATION.QCF
    • OK
  • Tab Destinations > New >
    • Queue of requests:
      • Name: JONATHAN.APPLICATION.REQUEST
      • Local JNDI Name: JONATHAN.APPLICATION.REQUEST
      • Remote JNDI Name: JONATHAN.APPLICATION.REQUEST
    • Queue of response:
      • Name: JONATHAN.APPLICATION.REPONSE
      • Local JNDI Name: JONATHAN.APPLICATION.REPONSE
      • Remote JNDI Name: JONATHAN.APPLICATION.REPONSE
    • NB: usually, MQ data are upper-cased and Java’s JNDI names are low-cased typed ; anyway (because of Windows not matching case?) here we use uppercase in for both names.

Mule

This part of the tutorial deals with a case of Mule ESB being your client application (sending and/or receiving JMS messages).

• Get the archive wlfullclient.jar (56MB). Alternatively, you can generate it yourself: go to the server/lib directory of your WebLogic installation (usually: C:\win32app\bea\wlserver_10.3\server\lib, and run: java -jar wljarbuilder.jar
• Copy the archive into $MULE_HOME/lib/user
• Copy the seven jars above (providerutil.jar, fscontext.jar, dhbcore.jar, connector.jar, commonservices.jar, com.ibm.mqjms.jar, com.ibm.mq.jar) into the same folder: $MULE_HOME/lib/user
• You can launch the mule. The config file is similar to any other configuration using standard JMS.