OutOfMemoryError

From time-to-time, you might see OutOfMemoryErrors in the SystemOut.log file for your WebSphere Application Server-based product (which includes WebSphere ESB and WebSphere Process Server). This normally happens when you’re putting the system under a large load (perhaps you have many applications running or are processing a lot of messages). This technote will help you resolve the problem, by explaining how to increase the maximum heap size used by the Java Virtual Machine running your server.

Overridding a Web Services Endpoint at Runtime in WebSphere ESB 6.0.1

Let’s say that you’ve developed a mediation module for WebSphere ESB 6.0.1 that contains a Web Services import (SOAP/HTTP). You’ve exported it from WebSphere Integration Developer (WID) as a .ear, but you realise, after deploying your application onto your runtime server, that you need it to point at a different Web Services endpoint (perhaps a different server). Here’s how you change it:

1. Go to the administrative console for your server.
2. Select ‘Applications/Enterprise Applications’.
3. Select the application (mediation module) that contains the import in question.
4. Select ‘EJB Modules’.
5. Select the EJB module from the list (there will be only one).
6. Select ‘Web services client bindings’.
7. Under ‘Port Information’, click ‘Edit…’.
8. In the ‘Overridden Endpoint URL’ box, you should see the current endpoint – as defined in WID. Change that to the URL you want, click OK, save your changes and restart your server.

Adding your own mediations to WebSphere ESB

WebSphere ESB comes complete with a set of mediation primitives from which you can build up your mediation logic. But what happens when the supplied mediation primitives do not allow you to build the mediation logic you require? Don’t despair, there are still a couple of options open to you.

Write your own custom mediation

Adding a custom mediation (one of the supplied primitives) is the simplest way to add your own custom mediation logic. This is effectively a place in the mediation flow that calls out to another SCA Component which you implement yourself to provide your own logic. There are 2 approaches for doing this:

- A top-down approach – the best choice if your mediation logic is very specific to this mediation flow and unlikely to be reusable. In this case, your custom mediation logic (which can be composed visually using the snippet editor or written in Java) is effectively encapsulated in the flow.

- A bottom-up approach – the best choice if your mediation logic is likely to be reused. In this case the custom mediation is effectively a call out to another service which provides the implementation of your mediation logic.

WebSphere ESB v6.0.2 simplifies both the top-down and bottom-up approach making it even easier to add your own mediation logic using a custom mediation. Nigel Daniels has written a good article on how to contribute custom mediations here.

Adding your own mediation primitive

If the mediation logic you want to add is something very generic that might be reused in a large number of situations, or you want to have a mediation primitive with a different terminal configuration, you should develop your own mediation primitive which can be added to the WebSphere Integration Developer mediation palette. This allows you to define your own icon, terminals and properties for your mediation primitive. This effectively involves developing an Eclipse plugin for inclusion in the WebSphere Integration Developer tooling and an implementation plugin for inclusion in the runtime. The instructions on how to do this can be found here. Future versions of the tooling we will aim to make this process simpler.

Using the techniques described above, pretty much any custom mediation logic can be added into the mediation flow.

Interactively Update the JVM Maximum Heap Size

If you’re using a product based on WebSphere Application Server, such as WebSphere Enterprise Service Bus or WebSphere Process Server, you might sometimes find that you run into problems relating to ‘OutOfMemoryErrors’ – these might appear in your SystemErr.log, or perhaps as an FFDC. They are likely to be caused by the Java Virtual Machine (JVM) heap running out of memory, and are more likely to happen if you have a lot of applications installed or you are stressing the server in some other way.

There are two values used by the JVM that runs your Application Server to control its heap size – the initial size and the maximum size. Most likely, you want to increase the maximum size. You’ll probably find that the default is 256MB, but to be sure, run:

startServer.bat server1 -script C:\temp\heapSize.bat

Replace server1 with the name of your server, and c:\temp with the name of any scratch directory. If you’re using a UNIX-based platform, replace .bat with .sh as appropriate. Now look at the generated batch file and search for -Xmx. It might look like -Xmx256m. This indicates your current maximum heap size is 256MB.

To increase this, let’s work with wsadmin interactively.

Run wsadmin.bat or wsadmin.sh:

wsadmin.bat -lang jython

-lang jython means that we want to use jython as the scripting language, rather than the default of JACL. jython is based on Python, which is simpler to learn and use than JACL. If your server is stopped, you should add -conntype none to ensure wsadmin can reach it. You’ll see a bunch of startup messages, then the wsadmin> prompt. Type the following command all on one line:

jvm = AdminConfig.list("JavaVirtualMachine").
split("\r\n")[0]

(use .split(”\n”)[0] on Linux/UNIX)

AdminConfig.list(”JavaVirtualMachine”) returns a list of JVMs, separated by newlines. If you’re using a standalone server, there probably will be only one, so you can omit the rest of the command. However, I’m using a clustered configuration, so I wanted to alter the heap size of only the first JVM in the list, which was a cluster member (I actually carried out these steps for each member of the cluster). Thus, I added the split method and the array subscript, which got me just the first JVM in the list. You can verify the JVM you’re using by typing:

print jvm

You should see something like this:

(cells/YOURCELLNAME/nodes/YOURNODENAME/servers/
YOURSERVERNAME|server.xml#
JavaVirtualMachine_1160406483174)

Next, type:

AdminConfig.modify(jvm, '[[maximumHeapSize 1024]]')

This will set the maximum heap size to 1024MB. Obviously, you can use a different value. As always, you must save your changes to the AdminConfig object:

AdminConfig.save()

You can now exit wsadmin by typing exit. Restart your server and you’re done. This entire procedure could be scripted instead (you can use the -f parameter to wsadmin to pass in a script), and that’s worth doing if you have to apply this change to a lot of servers.

WebSphere Process Server and WebSphere ESB Deployment Patterns

David Currie (a colleague of mine from the Hursley lab) writes on his blog about a useful set of new developerWorks articles. One of the most interesting of these is the start of a series or articles by Charlie Redlin and Karri Carlson-Neumann, two of the top people from the Rochester bring-up laboratory, describing the deployment patterns for WebSphere Process Server and WebSphere ESB. What these two don’t know about production topologies isn’t worth knowing, so I suggest you keep an eye on the series.

WebSphere Transaction and Messaging and WebSphere Technical Conference

Next week the WebSphere Technical Conference and WebSphere Transaction and Messaging Technical Conference are running in parallel in Salzburg. This is a great opportunity to find out more about the whole range of  IBM SOA related products given by some of the top people in IBM. I will be giving a couple of talks on WebSphere ESB on “Developing custom mediations” and “Connecting WebSphere ESB and WebSphere MQ”. I look forward to seeing you there.

WebSphere Message Broker 6.0.0.3

The latest fixpack for WebSphere Message Broker was just released. I’ll be downloading it as soon as I can. Check out the release notes.

The WebSphere SOA Runtime Stack

In a service oriented architecture approach there are a number of different types of services involved:

Simple services – the web services, or messaging applications exposed as services.

Mediation services – allow you to perform simple message mediation between services.

Business services – allow you to choreograph services.

Each of these services require a runtime with specific capabilities to be able to run.

The WebSphere platform supports these 3 types of service through 3 different runtimes: WebSphere Process Server, WebSphere ESB and WebSphere Application Server. The differences between these are described in the table below:

Runtime	Can host simple services	Can host mediation services	Can host business services
WebSphere Process Server	Yes	Yes	Yes
WebSphere Enterprise Service Bus	Yes	Yes	No
WebSphere Application Server	Yes	No	No

It won’t suprise you to learn that WebSphere Process Server is built on top of WebSphere ESB, and WebSphere ESB is built on top of WebSphere Application Server (I like to think of it like a Russian Doll – open up WebSphere Process Server and you will find WebSphere ESB, open up WebSphere ESB and you will find WebSphere Application Server). Consequently moving from one runtime to another is relatively simple as many of the concepts are the same, e.g. administration, clustering, configuration, install etc, etc. Plus, any of the things you could do at the lower level you can do at the higher level too if you choose to do so (i.e. you can host a simple service on WebSphere Process Server if you choose to do so).

These set of products effectively form the WebSphere SOA Runtime stack.

Protocol Transformation

This recently published Developerworks article gives an excellent overview of WebSphere ESB, as well as providing a detailed tutorial on protocol transformation, using the example of transforming a SOAP/HTTP service request into a SOAP/JMS one, as well as explaining how to use the Test Client facility in WebSphere Integration Developer. Worth taking a look if you’re new to the ESB concept or want a primer on WebSphere ESB.

JMS Clients External to a Cell

Based on a true story:

Let’s say that you’ve developed an ESB mediation module that exposes a JMS or SOAP/JMS interface via an export, and deployed it to your server. You’re writing a client to make requests to this export. Because you’re feeling lazy, you decide to use the connection factories that are automatically created for the export’s use, rather than create your own (which you should really do, particularly in a production environment). If your client is running of outside the cell that contains your server, this won’t work – you’ll get an error message when you try to connect. You will need to find the ‘Provider endpoints’ field for the connection factory in question in the administrative console, and add in hostnameofserver:7276 (assuming you are using the default port number). You’ll then need to save your changes and restart the server. Magic! It works.