HTTP transport nodes in WebSphere Message Broker V6

Introduction

Hypertext Transfer Protocol (HTTP) is a widely used standard protocol built on top of the TCP/IP stack for request/reply-based communications. The protocol is of course most commonly used by Web browsers to request pages from a server. With the development of the Enterprise Service Bus (ESB) technology and Service-Oriented Architecture (SOA), HTTP is becoming more widely used as the transport mechanism for invoking services, including Web services. HTTP is simply a protocol for communication between an HTTP client and an HTTP server. It does not let you interact with non-HTTP-enabled services in your enterprise.
The HTTP nodes in IBM® WebSphere® Message Broker V6.0.0.1 (hereafter called Message Broker) help you solve this problem. This article describes the HTTP nodes, shows you how to configure and use them, and discusses performance and scalability issues to consider when implementing message flows that use the HTTP nodes, including performance characteristics of several usage scenarios. For information on implementing Web services using WSDL, see Web services support in WebSphere Message Broker V6.

More about HTTP

The HTTP protocol was designed to be simple, fast, extensible, and compatible with previous versions. Although data retrieval using HTTP is efficient, the way connections are handled between client and server is not efficient where there are multiple requests for data. A new connection is required for each request/response pair, imposing a significant overhead on communications. To overcome this problem, HTPP 1.0 or later supports persistent connections between client and server, with multiple request/response pairs sent via the same connection. This function is available via the connection: keep-alive header and became the default in HTTP 1.1, with the client and server required to explicitly close the connection using the connection: close header. Persistent connection is very useful in some situations, such as when trying to repeatedly invoke a service, as a new socket no longer needs to be created for each request, dramatically improving performance.
HTTP is becoming a popular method for invoking services over TCP/IP, using standards such as Simple Object Access Protocol (SOAP) for the content of the request. Since HTTP and SOAP are widely used standards, this method is a good way to invoke a Web service, though you can also invoke services with other technologies and standards such as messaging (using WebSphere MQ for example), or SOAP over JMS. A key advantage of HTTP is that it is often not blocked by firewalls, enabling applications that use HTTP to be more available.

Integrating HTTP within the enterprise

A major advantage of HTTP is that it is a well-defined and vendor-neutral standard. HTTP by itself, however, is not suitable for all enterprise Web service invocations, because most large enterprises have many applications and services that are not HTTP enabled, and data from these applications often needs to be transformed before it can be understood by other enterprise applications. Yet many of these existing applications are well-defined, reliable, and high-performing, and therefore they often need to be integrated with the rest of the enterprise, instead of being re-architected or rebuilt.

HTTP transport nodes

Message Broker supports many different protocols, including:

• HTTP
• WebSphereMQ
• WebSphereMQ Telemetry Transport
• Multicast
• WebSphereMQ Real-time
• JMS Transport

HTTP transport nodes enable Message Broker to receive data from any HTTP client and send data back to that client. In addition, the nodes provide the ability to issue an HTTP request as an HTTP client.
The HTTP nodes act simply as a way of getting data into Message Broker. Once the data has arrived, all of the functionality normally associated with Message Broker is available. For example:
Data computations and transformations using:

• ESQL
• Java Computer nodes
• Enrichment of data from external sources
• Routing

There are three HTTP transport nodes in Message Broker:

HTTPInput node

Like other input nodes such as MQInput, the HTTPInput node obtains data from the client using HTTP as the communication protocol as opposed to WebSphere MQ or JMS. HTTPInput node supports several message domain formats for the incoming data:

• MRM
• XML
• XMLNS
• XMLNSC
• JMS
• JMSStream
• IDOC
• MIME
• BLOB

Once the data is received, HTTPInput node parses the data into the internal Message Broker message tree, enabling all normal Message Broker functionality to be used in the remainder of the message flow. An HTTPInput node must be in the same flow as an HTTPReply node, or it must pass the message to another flow containing an HTTPReply node, such as via an MQOutput node, because HTTP is a request/reply protocol and therefore a connecting client always expects a reply of some kind. HTTPInput node supports both HTTP and HTTP over SSL (HTTPS).

HTTPReply node

HTTPReply node sends a response back from Message Broker to the HTTP client that originally invoked the flow. The response is matched to the original request. The HTTPReply node must be in a flow that contains an HTTPInput node, or the original message must have been received from a flow that contained an HTTPInput node. The entire message tree is used as the body of the response.

HTTPRequest node

HTTPRequest node can be used within a message flow to enable Message Broker to invoke an existing HTTP-based service. The request can be made up of the entire message flow message tree or specified parts of it. You can augment the contents of the original input message (the request sent to the HTTP service) with the response from the HTTP service to create a new message before propagating it to subsequent nodes in the flow. HTTPRequest supports several different message domain formats for the incoming data:

• MRM
• XML
• XMLNS
• XMLNSC
• JMS
• JMSStream
• IDOC
• MIME
• BLOB

HTTPRequest supports both HTTP and HTTP over SSL (HTTPS).

Node configuration

More information on configuring HTTP transport nodes.

HTTP connectivity

The previous section described the HTTP nodes. This section explains how HTTP communication is handled between a Message Broker message flow and a client that may invoke the message flow, or an HTTP-based service that can be invoked from within a message flow.

Broker as server

The client must be capable of using the HTTP protocol. Receipt of HTTP requests in Message Broker is handled through a listener process called biphttplistener. Figure 1 below shows how this interaction takes place. The HTTP request issued by the client is received by the Message Broker listener process. The message is then passed to the HTTPInput node and processing within the message commences. Upon completion of the message flow, the HTTPReply node issues a response, which is sent to the HTTP client through the Message Broker HTTP listener process.

Figure 1. HTTP request and response

There is a single multithreaded (configurable) biphttplistener process for each Message Broker instance. The biphttplistener process is resilient -- if it fails, it automatically restarts. A single listener serves all flows containing an HTTPInput node deployed to a single broker. You can, however, filter the incoming HTTP requests to different flows based on the incoming URL by setting properties on the HTTPInput node. You can use the entire URL or a pattern. For example, if the URL that you want is http://<hostname>[:<port>]/[<path>], then specify either /<path> or /<path fragment>/*, where * is a wild card.

Broker as client

When the interaction is with an HTTP-based service, the processing sequence is different and involves a different processing node. Figure 2 shows how a message flow invokes an HTTP-based service. In this case, the message flow is acting as a client using the HTTPRequest node:

Figure 2. HTTP-based service

Technology benefits and business value

So far we have focused on what the HTTP Transport nodes are and how you can configure and use them within a message flow. This section uses some common usage scenarios to show how you can use the nodes to add value to your existing enterprise messaging infrastructure. Scenarios featured in this section will also be the scenarios featured within the section Performance characteristics and scalability.

Facade an existing application

When implementing an SOA, many of the services that you want make available across your enterprise will probably not be HTTP enabled. A number of applications may perform key business processing and must be used across other areas of the enterprise. By HTTP-enabling such applications or pieces of function using the HTTPInput and HTTPReply nodes, you can make them more easily accessible. This article discusses two types of applications that you can facade using WebSphere Message Broker -- WebSphere MQ enabled and non-WebSphere MQ enabled, such as a DB2 stored procedure or a CORBA application.
For WebSphere MQ enabled applications, a typical scenario involves a request/reply application:

Figure 3. Request/reply application

In this scenario, you start with an HTTPInput node to construct Flow1, which receives a request from an HTTP Client. This request is for a WebSphere MQ enabled service. The request is transformed into the appropriate format, including WebSphere MQ headers, and placed on the queue that the business application reads from. The request identifier of the incoming message is also stored to enable coordination of replies from the application back to the requesting HTTP Client by Flow2.
The business application performs its operation and places the resulting message on its output queue, where it is picked up by the Reply message flow, Flow2, through a standard MQInput node. The request identifier is retrieved for this message, the message is transformed into the appropriate format including HTTP headers, and then sent back to initial requesting HTTP Client via the HTTPReply node.
This process is straightforward and the created message flows are simple. Once the HTTP Request has entered Message Broker, all the normal functions are available. As demonstrated, you can do conversion between message formats -- XML to Custom Wire Format -- and thereby communicate with an array of external applications.
Not all applications or pieces of business processes that you want to expose as services will be WebSphere MQ enabled. Examples include a DB2 stored procedures or a CORBA application. For non-WebSphere MQ enabled applications, imagine a "straight-through" scenario:

Figure 4. Non-WebSphere MQ enabled application

In this scenario, the message flow receives a request from an HTTP client and the requested application, a DB2 stored procedure, is called from within a Compute node. Parameters for the application are extracted from the incoming HTTP Request message and converted into the appropriate format. You make a synchronous call to the application and receive a response, which is built into the original HTTP request message and sent back to the HTTP client as an HTTP response. Again, this is a very simple message flow but very powerful.
The HTTP client is only aware of a synchronous call. The contents of the message flow may be either synchronous or asynchronous, which is transparent to the requesting client and thus offers considerable flexibility in the way the service is composed.
In addition to the composition of the message flow, you need to consider the duration of the connection between the HTTP client/server and the message flow. You can configure the HTTP connection as either short-lived or long-lived.
The short-lived, non-persistent connection is best when many (hundreds or thousands) of clients want to make individual requests and then disconnect. You should not maintain large number of connections in this case because of the memory and other resources required.
The long-lived, persistent connection is best when a small number of requesting applications need high volume message throughput. Long lived connections avoid the overhead of session creation and deletion. This connection is common when a concentrator application funnels requests to a message flow from a large number of users.
Both short- and long-lived connection types are supported in Message Broker V6.0.0.1. Configuration details are covered below under Performance and tuning.

Issue an HTTP Request from within the messaging backbone

Another common usage scenario is invoking services that are already HTTP enabled. You can do this using the HTTPRequest node:

Figure 5. HTTP-enabled services

In this scenario, you construct a message flow to read a message from a WebSphere MQ queue via an MQInput node. You store the MQ headers before making a synchronous call to an HTTP service via an HTTPRequest node, using the body of the MQ message as the body of the request (this option is configurable). You receive the response from the HTTP service and use it along with the original stored MQ headers (again, this option is configurable) as the response message written to the WebSphere MQ queue. As above, the message flow is simple to construct and all normal Message Broker functions are available.

Facade an existing HTTP Service

You have seen that you can facade an existing business application as HTTP services, and also call existing HTTP services from within the messaging backbone. An additional scenario is to enrich existing HTTP services, in which you want to invoke an existing HTTP, but also add value to it via Message Broker function. You can do this using the HTTPInput node, HTTPRequest node, and HTTPReply node:

Figure 6. Call existing service

In this scenario, you construct a message flow to receive a request over HTTP from an HTTP client, which is modified to issue a request to the URL of Message Broker instead of the URL of the existing HTTP Service. Archive the HTTP request into a database for audit purposes before forwarding the original request to the existing HTTP service, then forward the response from the HTTP service back to the HTTP client. This scenario demonstrates the auditing of incoming requests, but it does not have to be restricted to such usage. You can use any Message Broker function to enrich an existing HTTP service. This scenario is not included in the Performance characteristics and scalability section below as it is really a simple extension of the three previous scenarios.

Load balancing and failover

To build a system that can process a high volume of messages and provide high availability, you need to determine the availability level required and whether it is acceptable to have data marooned if a server or message broker fails. Remember, it may not be just the original request that is held up, but also any intermediate processing running on the failed server. The two main availability approaches are load balancing and automatic failover of processing components such as Message Broker.
Load balancing is the distribution of incoming work across a pool of available servers or message brokers so that a higher volume of work can be completed. Load balancing can increase system availability by routing requests around failed or poorly performing message brokers, provided that the load balancer monitors the health of each of the servers via health monitoring probes or "heartbeat processing." Here are two approaches for increasing availability:

Load balancing with a pool of servers

Even if one or more servers fail it will be possible to continue to provide a service using the other servers in the pool. However in the event of a server failing there is the likelihood that some data will become marooned on the failed server .This would remain so until the server was restarted. If the problem were hardware related this could take some time to recover from.

using software such as HACMP that is able to restart a failed server automatically on another machine

This has the advantage that no data will be marooned. There will be a short delay while the server is restarted one another system, but once it is restarted the original data is still accessible. With WebSphere Message Broker V6 you can use HACMP to restart a failed broker on another system. This approach has been used widely in the past where the incoming work is from WebSphere MQ clients. It works equally as well when the incoming work is from an HTTP client. You should bear in mind though that the incoming request is not recoverable unless it is logged in some way, this is wholly consistent with the nature of the transport protocol.

The remainder of this section focuses on the use of different load balancing solutions and discuss the merits of them. Software to provide high availability, such as HACMP is not discussed any further. Here is a diagram of an environment that can provide load balancing and availability (but no recovery):

Figure 7. Load balancing and availability

This diagram shows that you can connect multiple HTTP Clients to the same URL and to any number of back-end Message Brokers by using a network dispatcher such as WebSphere Edge Server Load Balancer. The number of server instances is variable, which makes it easy to increase message throughput capacity using horizontal scaling.
Using the network dispatcher lets you distribute workload across all connected brokers. The mechanism for doing this is configurable -- for example by rotating through a check of server response times. Using a network dispatcher also adds failover capabilities by verifying whether the HTTP listener port is functioning on each of the connected servers. It tries to establish a TCP connection from the dispatcher to each of the servers, and if it fails, it marks that server as down stops forwarding requests to that broker's HTTP listener.
With WebSphere Edge Server, more advanced health checks are available using pre-packaged advisors. You can also write custom advisors to implement your own health checks.
An alternative architectural approach is shown in Figure 8:

Figure 8. Moving HTTP connection processing away from broker by using a proxy

This setup is similar to the one in Figure 7, but moves the HTTP connection processing away from the broker by using a proxy. The proxy is a servlet engine running inside an application server such as WebSphere Application Server and acting just like the Message Broker internal process in Figure 1. The servlet engine is available as a Category 3 SupportPac.
As shown in the diagram above, a proxy servlet can service only a single Message Broker. You can, however, have many proxy servlets connecting to a single Message Broker.
The Network Dispatcher is used purely for distributing the incoming HTTP requests. It is not a prerequisite to the proxy servlet. The main reasons for using a proxy servlet architecture is its ability to support a greater number of concurrent connections than you can with the default listener. By using multiple copies of the proxy servlet you can support more concurrent users. For details on setting the number of concurrent connections, see Performance considerations and tuning below. Message Broker can support about 1200 concurrent connections to a broker biphttplistener process. Of course if you need to support fewer than 1200 concurrent sessions, then you do not need to use the Proxy Servlet in this role.

Using transactions with HTTP

HTTP messages are always non-persistent, and have no associated order
HTTP messages are non-transactional. However, if the message flow interacts with a database or another external resource such as a WebSphere MQ queue, these interactions may be performed transactionally if configured to do so. The HTTPInput node provides commit or rollback depending on how the message flow has ended, and how it is configured for error handling (how failure terminals are connected, for example). If the message flow is rolled back by this node, a fault message is generated and returned to the client. The format of the fault is defined by the Fault Format property.
If an exception occurs downstream in the message flow, and is not caught but is returned to the HTTPInput node, the node constructs an error reply to the client. This error is derived from the exception and the format of the error is defined by the Fault Format property.

Performance considerations and tuning

You can use a standard installation of Message Broker in your enterprise to handle HTTP and issue HTTP requests. In some cases you many need to tune Message Broker to achieve a higher level of throughput. This section discusses the standard configuration and how to modify it.

Persistent connections

Message Broker supports both HTTP 1.0 and 1.1 and can therefore handle persistent connections. When dealing with a small number of requesting applications that need a high volume of message throughput, possibly by using a concentrator application funneling requests to a message flow, you should use a persistent connection to prevent the unnecessary creation and deletion of sockets for each connection. If the HTTP client uses HTTP 1.1 and does not specify the Connection: close request header, persistent connections will be used by default. However, there is a configurable property called maxKeepAliveRequests that specifies how many requests can be send down a single connection.
The default Message Broker value is 100. Therefore, when an HTTP client connects, it can send 100 requests before Message Broker issues a Connection: close and closes the socket. The next request the client sends creates a new socket and again can send up to 100 requests. In many environments this setting may be enough. But when maximum throughput is required, you may need to set this value higher or make it unlimited, in order to achieve the desired throughput.
Here is the command: mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxKeepAliveRequests -v 0.

MyBroker

Name of the Message Broker

-b

Component you are changing

-o

Object within the component you wish to change

-n

Name of specific parameter to change

-v

Value

In the above command a value of 0 is specified, which sets the number of requests allowed down a single socket to unlimited. This setting is used for the measurements shown below in the section Performance characteristics and scalability.
As noted in previous sections, you can call HTTP services from Message Broker, which acts like any other HTTP client and can thus create persistent connections. The HTTPRequest node has a configuration option to use keep alive connections, though it is supported only when you select HTTP 1.1. The value of the maxKeepAliveRequests parameter on the server that the HTTPRequest node is connecting to determines how frequently a new connection is created.

Concurrent connections

In addition to dealing with a small number of long-lived connections by using persistent connections, you may also have a large number of short-lived connections involving hundreds or thousands of clients that want to make individual requests and then disconnect. The HTTP client can issue an HTTP request with Connection: close specified in its headers, which ensures that a new connection is created for each new request.
You can set the maxThreads parameter to determine the maximum number of concurrent connections that Message Broker will accept. But machine resources, such as amount of addressable memory, determine the absolute maximum number of concurrent HTTP client connections that you can make to Message Broker, and these resources may be exhausted before the maxThreads limit is reached.
The default value is 250, which means the 251st client that tries to connect will get a Connection Refused response. (Actually, a few connections in excess of the maxThreads value may be allowed, because connections can be queued up to the limit set by the acceptCount parameter, which is again configurable). In many environments, the default setting may be enough, but in some cases you may need to set this value higher by running this command: mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxThreads -v 2000. (For the meanings of the parameters, see above list.)
The above command sets the number of concurrent connections allowed to 2000. This setting is used for the measurements shown below in the section Performance characteristics and scalability.
Increase the heap size of the JVM running within the biphttplistener process to let the JVM allocate more threads for the incoming connections. The default setting for the listener JVM is 192 MB, but you should increase it to 512 MB when dealing with large numbers of concurrent connections. To change the value, modify the Message Broker registry.
Windows®
Under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphereMQIntegrator\2\<BrokerName>\CurrentVersion create a new String value named MaxJVMHeapSize. Set this new String value to the JVM maximum heap size required in bytes. For example: 536870912 for 512 MB.
UNIX®
In the directory <Broker File Path>/<Broker Name>/CurrentVersion/, create a new file named MaxJVMHeapSize. Set the contents of this file to the JVM maximum heap size required in bytes. For example: 536870912 for 512 MB.
For the changes to take affect, you will to stop and restart Message Broker.
The methods described above increase the specific JVM that the biphttplistener process runs within. This JVM is separate from the one for the execution group processes, and therefore cannot be modified using the mqsichangeproperties command.
When dealing with large numbers of open sockets (a single socket per concurrent connection) the operating system may limit the number of files that a single process can open at one time. On UNIX, the limit for the number of files that a process can open also applies to sockets, and therefore you need to increase the maximum open file handles setting to reflect the expected number of concurrent connections. To check the current setting, run the command ulimit -a. For help in increasing this setting, see your system administrator. Normally you can change it with the command ulimit -n 4096.
This setting is only for UNIX. When running with the above parameters, maxrtheads=2000, JVM=512, ulimit=4096 (where appropriate), 1200 concurrent connections were created using a single Message Broker instance on Solaris, Windows, and AIX, because of the hard limit being reached in WebSphere MQ.

Performance tuning the HTTPRequest Node

By default, the HTTPRequest node uses the platform default for its sockets tcpnodelay setting. This setting disables the use of Nagles Algorithm, which is a TCP feature that buffers up small packets into a single large packet for more efficient transmission. This setting can briefly delay the transmission of smaller packets, especially on some platforms. For example, on AIX, it has resulted in poor response time and throughput when sending small messages using the HTTPRequest node. To disable Nagles Algorithm, use this setting:

mqsichangeproperties <BrokerName> -e <ExecutionGroupName> -o 
  ComIbmSocketConnectionManager -n tcpNoDelay -v true

It is much more efficient from a performance perspective to use persistent HTTP connections. To ensure that the HTTPRequest node uses persistent connections, check the box on the node labeled "Enable HTTP/1.1 keep-alive" under "HTTP Settings" on the node properties. The remote end to which you are connecting must also be configured to accept persistent HTTP connections, and this configuration depends on the Web service provider/HTTP Server you are using. By default, the socket used in the request node is recycled every 90 requests. To set the node to use the same socket for an unlimited number of requests, use the command:

mqsichangeproperties <BrokerName> -e <ExecutionGroupName> -o 
  ComIbmSocketConnectionManager -n  maxKeepAliveRequests -v 0

However, even with this setting, the socket will be closed if it is idle for more than four seconds. After you run either of the commands above, you must stop and restart the broker. To verify whether persistent connections are being used, use the command netstat -a on the broker machine to check the connections between it and the remote server. The number of sockets in use should be equal to the number of flow instances -- in other words, one connection per thread.

Performance characteristics and scalability

This section contains throughput results when running a number of test cases. The tests include those discussed in this paper plus a number of high-volume simple test cases. To reduce the number of tests, only the 1K message size was scaled across execution groups.
Windows

Figure 9. Throughput results on Windows

Solaris

Figure 10. Throughput results on Solaris

As you can see on Windows and Solaris, both the HTTPInput Node/HTTP Reply Node pair and the HTTPRequest node perform well. All of the test cases also scale well up to the point where no CPU resources are left, which occurs at different points depending on the test case and the number of CPUs in the machine.

Machine details

Windows
Hardware:

• 1 IBM xSeries 360 with 4 2.00 GHz Intel Xeon processors
• 3 69 GB SCSI hard drives formatted with NTFS
• 4 GB RAM
• 1 GB Ethernet card

Software:

• Microsoft Windows 2000 with Service Pack 4
• WebSphere MQ V6
• WebSphere Message Broker with V6 with Fix Pack 1
• DB2 for Windows V8.1 with Fix Pack 4

Solaris
Hardware:

• 1 Sun Fire V1280 Server with 8 1.2 GHz processors
• 2 72 GB SCSI hard drives
• 1 StorEdge Fast 3510 array with 2 LUN's and fastwrite cache -- 2 275 GB and 16 GB of RAM
• 1 GB Ethernet card

Software:

• Solaris 9
• WebSphere MQ V6
• WebSphere Message Broker V6 with Fix Pack 1
• DB2 for Solaris V8.1 with Fix Pack 4

Conclusion

This article has explained the role and function of the HTTP transport nodes in WebSphere Message Broker V6.0.0.1. It has shown how you can use the nodes to address a number of scenarios, including:

• Facade an existing application, either WebSphere MQ enabled or non WebSphere MQ enabled
• Facade and enrich an existing HTTP service
• Request an HTTP service from within an existing messaging backbone

WebSphere Message Broker HTTP transport nodes let you develop solutions to the above scenarios quickly and easily. Complex recoding of existing services is not needed -- instead they can be HTTP-enabled through drag and drop development of Message Broker flows, thus greatly reduce the cost of incorporating HTTP services into existing enterprise applications. This article also discussed performance and scalability considerations when designing your message flow applications.

WebSphere MQ Publish/Subscribe and JMS

Message-oriented middleware decouples applications communicating by using two messaging models: point-to-point messaging and publish/subscribe messaging. 

Lets see here how publish/subscribe messaging is used for communication between two JMS applications making use of the administrative features of publish/subscribe provided in WebSphere MQ v7.

What is publish/subscribe?

Publish/subscribe messaging allows you to decouple the provider of information, from the consumers of that information. The sending application and receiving application do not need to know anything about each other for the information to be sent and received.

Components of publish/subscribe

Publisher -  This component generates messages (publications) under a certain subject (topic) and sends the publications to a WMQ queue manager. A publisher knows nothing about the recipient(s) of the information.

Subscriber - This component registers interest in a certain topic(s) with a WMQ queue manager. It also specifies its subscription queue name; that is, the queue where it wants to receive the messages related to this topic. The subscriber knows nothing about the information publishers(s).

Publications Router -  This component passes messages from publishers to topic subscribers. Generally this is a Queue Manager.

What is Topic and how is it different from Queue?

A topic is a character string that describes the subject of the information that is published in a publish/subscribe message. A queue is always associated with a specific address and can be used only in one-to-one communication. A topic has no logical address associated with and can be subscribed or published by many and hence can be said used in one-to-many or many-to-one communication. In WebSphere MQ you can create a Topic in same way as a queue and has a default system object called SYSTEM.DEFAULT.TOPIC.

From WebSphere MQ v7 Queue Manager is used as the publications router and we can define administrative objects like Topics and Subscriptions through WebSphere MQ Explorer.Prior to this a Broker component was used for this.
 Also WebSphere MQ Explorer is used to create JMS Administered objects required by the applications to communicate with each other.WebSphere MQ Explorer is used to create and configure connection factories and destinations as administered objects in a JNDI namespace. An application can then retrieve the administered objects from the JNDI namespace.
Connection factories and destinations are starting points in the flow of logic of a JMS application. An application uses a ConnectionFactory object to create a connection to a messaging server, and uses a Queue or Topic object as a target (destination) to send messages to or a source (destination) from which to receive messages. 

IBM WebSphere MQ classes for Java Message Service (also referred to as WebSphere MQ JMS) is a set of Java classes that enables the JMS applications to access WebSphere MQ systems.  The JMS application is written to use only references to the interfaces in javax.jms package. All vendor-specific information (IBM WebSphere MQ) is encapsulated in implementations of the following JMS administered objects:

ConnectionFactory

QueueConnectionFactory
TopicConnectionFactory
Queue
Topic

The Java classes of the IBM WebSphere MQ JMS provider communicate with the queue manager through Connection factories using one of the following transport options: 

1. As an IBM WebSphere MQ client using TCP/IP
2. In bindings mode, connecting directly to IBM WebSphere MQ

A publish/subscribe scenario 

A news broadcasting company A sends various channels of news to its clients C and D through email and sms. For e.g take sports news. In point-to-point messaging this is achieved by company A put messages in email and sms queues defined for companies C and D. The destination needs to be known by company A to do this. But in publish/subscribe messaging company A publishes the sports news messages to a component called Topic. The interested clients C and D can subscribe to this topic and provide their subscription queue names where they like to receive the messages.This allows full decoupling of applications involved in messaging. Company A does not know about their Sports News channel subscribers C and D and vice versa. Now if the company A like to create a new news channel for entertainment all it has to do is define a new topic in the intermediate queue manager used for messaging.

How to setup publish/subscribe using WebSphere MQ JMS and WebSphere MQ Explorer v7

1. Create a queue manager.
2. Create a news topic.
3. Create subscription queues.
4. Create subscriptions.
5. Create Java Messaging Services (JMS)-administered objects.
6. Create a Connection Factory
7. Create Destinations
8. Write publisher and subscriber classes. [Applications]
9. Run the classes.

1. Create a Queue manager

In MQ Explorer's Navigator view, right-click Queue Managers and then select New > Queue Manager. This starts the "Create Queue Manager" wizard.On Step 1, enter TestQM1 as the queue manager name and then click Next until you reach the screen to enter port number. Make sure the port number you enter is not used by other Queue Manager. Finally click Finish.

2. Create a news topic.

Under TestQM1, right-click Topics and then select New > Topic to start the "New Topic" wizard. Type News.Topic as the topic name and click Next. On the topic properties page, type News in the "Topic string" field and click Finish.

3. Create subscription queues.

Under TestQM1, right-click Queues then select New > Local Queue to start the "New Local Queue" wizard. In the name field, type Email.Queue and click Finish. Repeat the same for SMS.Queue.

4. Create subscriptions.
Under TestQM1, right-click Subscriptions and then select New > Subscription to start the "New Subscription" wizard. In the name field, type EmailSubscription and click Next. In the "Change properties" page, press the Select button next to the "Topic name" and then select News.Topic from the displayed topics list. Press OK. On the same page, type Email.Queue in the destination name field and click Finish.

Repeat the above steps to create another subscription called SMSSubscription with the topic set to News.Topic and the destination name set to SMS.Queue.

Quick Test for the Publish/Subscribe setup Created.

Under TestQM1, click Topics. In the right pane, right click News.Topic and select "Test Publication" to open the test window. In the message data field, type "pub/sub msg1" (or any other text), click the "Publish message" button, and then click the Close button. This should distribute the message to the subscriber queues Email.Queue and SMS.Queue. You can right click on Email.Queue and click Browse Messages...You will find the same message in the Message Data column. Right Click the Queues and Clear Messages... after testing.

5. Create Java Messaging Services (JMS)-administered objects.

To store JMS-administered objects, create a file-based Java Naming and Directory Interface (JNDI) namespace. Start by adding a new initial context. Right-click JMS-Administered Objects and then select Add Initial Context.Select "File System" for "Where is the JNDI located."For the Bindings directory, browse to C:\JNDI-Directory (This directory has to exist). Click Finish. 

Note::Make a note of Factory class "com.sun.jndi.fscontext.RefFSContextFactory" and Provider URL "file:/C:/JNDI-Directory/". This will be used in the Java code later.

6. Create a Connection Factory

Right-click Connection Factories and then select New –> Connection Factory. On the first screen, type TestQM1ConnectionFactory in the name field and click Next. Click Next till last page. On the last page, select the connection tab (on the left) and then click the Select button to select TestQM1 as "Base queue manager". Click Finish.

7. Create Destinations

Right-click destinations and select New –> Destination to start the "New Destination" wizard.
In the first step, enter NewsTopic in the Name field and change the Type field to Topic. Click Next till last page. On the last page (Change properties), type News in the Topic field and then click Finish.

Right-click destinations and then select New –> Destination to start the "new Destination" wizard. In the first step, type EmailQueue in the Name field and then click Next. Click Next on the second screen. On the last page, click the Select button next to the "Queue Manager" field and select TestQM1 from the list. Click the Select button next to the Queue field and select Email Queue from list and click Finish.
Repeat the above steps to create another Destination called SMSQueue for SMS.Queue.

8. Write publisher and subscriber classes.

Now all the configurations involving JMS Administered objects and MQ Explorer are complete we can write the JMS Applications.

The Applications will be simple.
Publisher Application write a message to a Topic.
Subscriber Application read messages from Subscription Queues.

Lets see what are the java classes [Applications] about. The Applications use JMS Interfaces [API] which treat queues and topics uniformly as destinations. You have a utility class and a Publisher class and two Subscriber classes.

JNDIUtil Class

This class includes generic methods which retrieve JMS objects through JNDI lookup. Get the InitialContext and assign it to a Context object.Generic methods in this class are used to retrieve references to the JMS objects already defined.getObjectByName()getConnectionFactory()getDestination()

NewsPublisher Class

This class publishes messages to News Topic
Get a ConnectionFactory through lookup and use the factory object to create a Connection

factory= jndiUtil.getConnectionFactory("TestQMConnectionFactory"); 
connection = factory.createConnection();

Use the connection object to create a session

session = connection.createSession( transacted, Session.AUTO_ACKNOWLEDGE);

To publish messages retrieve a News destination object and create a MessageProducer and then send messages:

destination = jndiUtil.getDestination("NewsTopic");
producer = session.createProducer(destination);
TextMessage message = session.createTextMessage("No News is Good News!");
producer.send(message);

EmailSubscriber and SMSSubscriber

These applications read messages from the Subscription queues. It uses a MessageConsumer to retrieve messages from queues:

consumer = session.createConsumer(destination);TextMessage iMsg = (TextMessage) consumer.receive(1000);

9. Run the classes

Now since the setup is complete you can run the Java Classes.

The JAR files required to compile and run the sample classes are automatically added to the CLASSPATH environment variable when you install WMQ. The required JARs are located in C:\Program Files\IBM\WebSphere MQ\Java\lib, including the JARs you need for JMS and JNDI. You just need to add the sample classes from the code to your CLASSPATH environment variable.

To publish messages, run the NewsPublisher:

java <packagename>.NewsPublisher

Run both subscribers after your run the NewsPublisher to retrieve messages. Each class should retrieve its own copy of the messages published by NewsPublisher:

java <packagename>.EmailSubscriber
java <packagename>.SMSSubscriber

Credits: The complete credit goes to the original content and author in the below link. Source code is available for download.

http://www.devx.com/Java/Article/41921

Starting accounting and statistics data collection in the WebSphere Message Broker Explorer

Use the WebSphere® Message Broker Explorer to start collecting snapshot accounting and statistics data for your brokers, execution groups, and message flows. You can then view the accounting and statistics data in the Broker Statistics and Broker Statistics Graph views.

Before you start:

• Ensure that you have created a message flow; for more information, see Creating a message flow.
• Ensure that you have deployed a broker archive (BAR) file; for more information, see Deploying a broker archive file.
• Read the concept topic, Message flow accounting and statistics data.

Use the snapshot accounting and statistics data displayed in the Broker Statistics and Broker Statistics Graph views to monitor the performance and resource usage of your broker or execution group at the message flow, node, or terminal level.

You can start collecting accounting and statistics data for an active broker at any time. You can start collecting accounting and statistics data for multiple brokers at the same time.

To start collecting snapshot message flow accounting and statistics data by using the WebSphere Message Broker Explorer:

1. In the WebSphere MQ Explorer - Navigator view, expand the Brokers folder.
2. Right-click the execution group or message flow for which you want to collect statistics.
   • If you selected an execution group, click Statistics All Flows > Start Statistics.
   • If you selected a message flow click Statistics > Start Statistics.
   A message is sent to the broker to start collecting accounting and statistics data for the selected resource.
3. Click Window > Show View > Broker Statistics to open the Broker Statistics and Broker Statistics Graph view. These two views are displayed together. If you close one of the views, the other view is also closed.

Accounting and statistics data for the selected broker, execution group, or message flow is displayed in the Broker Statistics and Broker Statistics Graph views. It can take up to 30 seconds for accounting and statistics data to be received from the broker and displayed in the Broker Statistics Graph view. The message Waiting for Data is displayed in the title bar is displayed until accounting and statistics data is received from the selected broker, execution group, or message flow. When data is received from the broker, it is displayed in numeric form in the Broker Statistics view, and a visual representation of this data is shown in the Broker Statistics Graph view. Select individual or multiple items in the Broker Statistics view to change the information displayed in the Broker Statistics Graph view.

Next:

To examine the current data in the two views, click Pause in the Broker Statistics Graph view to prevent the current data from being overwritten with new data. Click Play to resume displaying more accounting and statistics data. You can change the visual representation of the data by clicking Linear, Logarithmic, and Stacked.

You can also select the metrics that are displayed in the graph view; for more information, see Filtering message flow accounting and statistics data.

Related concepts:

WebSphere Message Broker Explorer

Message flow accounting and statistics data

Related tasks:

Viewing message flow accounting and statistics data

Stopping accounting and statistics data collection in the WebSphere Message Broker Explorer

Filtering message flow accounting and statistics data

Related reference:

Metrics for accounting and statistics data in the WebSphere Message Broker Explorer

IBM Integration Bus and WebSphere Message Broker FAQ for Memory

Technote (FAQ)

Question

The following is a list of answers to frequently asked questions (FAQ) about Memory related problems in IBM Integration Bus (IIB) and WebSphere Message Broker (WMB) for new and experienced users

Answer

Index of questions in this document:

• 1. Is there a memory leak in my DataFlowEngine?
• 2. Why is my DataFlowEngine memory usage not reducing on the UNIX systems?
• 3. How can I monitor JVM memory usage of a DataFlowEngine process?
• 4. How can I tune JVM heapsize for a DataFlowEngine, bipbroker and biphttplistener processes?
• 5. How can I monitor memory usage on Windows and UNIX?
• 6. I see an abend with an out of memory error. What could be causing this failure?
• 7. How do I isolate the problem of memory growth to a particular message flow?
• 8. How does WebSphere Message Broker (WMB) handle the memory usage within a DataFlowEngine (DFE) Process?
• 9. What is memory fragmentation in a DataFlowEngine process?
• 10. How can I tell if the out of memory is caused due to the DataFlowEngine running out of JVM Heapsize or total process memory?
• 11. Are there any useful references in the area of broker/execution group memory usage?
• 12. What should I do in a broker to process a very large message?
• 13. What is MQSI_THREAD_STACK_SIZE and do I need to set it?
• 14. Are there any needs for modifying the system kernel parameters for WMB/IIB?
• 15. How do you set the limit of total memory consumed by the DataFlowEngine process?

1. Is there a memory leak in my DataFlowEngine?

During message processing, it is possible for execution groups to continue to grow in memory usage. This could be due to a number of factors and does not necessarily indicate that there is a memory leak. The following link provides information on the Execution group memory growing behavior and the reasons.

http://www-01.ibm.com/support/docview.wss?uid=swg21106136

Back to top

2. Why is my DataFlowEngine memory usage not reducing on the UNIX systems?

DataFlowEngine acquires memory while processing messages through its message flows. The amount of memory required to process messages depends on the size of the messages. After some processing, the DataFlowEngine acquires enough memory that it can internally re-use the memory for all the subsequent messages that are processed through its message flows. The UNIX process holds on to the memory anticipating that it could be required for subsequent processing of messages and to avoid performance impact due to releasing and reacquiring memory.

Back to top

 

3. How can I monitor JVM memory usage of a DataFlowEngine process?

JVM memory usage by an execution group can be monitored using resource statistics. The following Information center page gives more information on this.

http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/topic/com.ibm.etools.mft.doc/bj43370_.htm

Use MBX explorer and/or WebUI to enable and view resource statistics
- Register subscriptions and use command line parameters to monitor the resource statistics
http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/topic/com.ibm.etools.mft.doc/bj43320_.htm

- Export the following env variable in the broker service Id's profile and restart the broker to monitor the garbage collection (GC) in broker -
export MQSIJVERBOSE=-verbose:gc
OR

- You may run the following command at the execution group level and restart just the execution group -

mqsichangeproperties <broker> -e <EG> -o ComIbmJVMManager -n jvmSystemProperty -v"-verbose:gc -Xverbosegclog:<path to gc.trc>

Once the output is collected, you can use the IBM Support Assistant (ISA) workbench, a GUI based application to view the GC activity in graphical form. The ISA workbench can be downloaded from the following IBM site:
http://www.ibm.com/software/support/isa/download.html
After download, you can go to Update > Find updates and add ons to install "IBM Monitoring and Diagnostic Tools for Java - Garbage collection and Memory Visualizer". This will install the tool that can now be used to view the garbage collection activity.  You can use this tool to analyze the stdout file.

Back to top

4. How can I tune JVM heapsize for a DataFlowEngine, bipbroker and biphttplistener processes?

JVM maximum and minimum heapsize can be tuned using mqsichangeproperties command. The following online documentation gives more information

http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/ac55070_.htm

Please see the following link for bipbroker and DataFlowEngine processes:
http://www-01.ibm.com/support/docview.wss?uid=swg21198739

For biphttplistener process:
http://www-01.ibm.com/support/docview.wss?uid=swg21626362

Back to top

5. How can I monitor memory usage on Windows and UNIX?

At any given point, you can check the memory usage for processes in the following way:

Windows:
Ctrl-Alt-Delete > Start Task Manager > Processes > Show processes for all users and go to the process "DataFlowEngine" and look at the field "Memory (Private working set)

If you want to continuously monitor the memory usage, then check the following link for Windows sysinternals for process utilities: http://technet.microsoft.com/en-us/sysinternals/

UNIX:
ps -aelf | grep <PID for DataFlowEngine>

If you want to continuously monitor the memory usage, then the above command may have to be incorporated into a simple shell script.

Back to top

 

6. I see an abend with an out of memory error. What could be causing this failure?

An out of memory error in an abend file indicates the process has terminated as it could not acquire more memory to continue processing. The memory required for processing could be native memory or java heap memory. Investigation would be required to identify why the process was unable to acquire more memory. If using java compute nodes, it is a good practice to tune JVM Heapsize for the environment. Refer to the questions below to gain better understanding of this subject to be able to carry out the investigation.

Back to top

7. How do I isolate the problem of memory growth to a particular message flow?

Separating the message flows that are deployed to an Execution group into multiple Execution Groups would allow you to recreate the problem with isolated sets of message flows deployed to their own execution groups and thus allow you to identify the specific message flows that may be contributing towards memory growth for that execution group.

To identify a potential memory leak, the same input message should be repeatedly sent into the message flow. When a message flow processes the same input message over and over again, then this should drive the same message flow paths each time. When this happens then we would expect the DataFlowEngine process to plateau very quickly unless the flow had experienced an expected growth.

Back to top

8. How does WebSphere Message Broker (WMB) handle the memory usage within a DataFlowEngine (DFE) Process?

When considering memory usage within a DataFlowEngine process there are two sources that the storage is allocated from, and these are :
1. The DataFlowEngine main memory heap
2. The operating system

When message flow processing requires some storage, then an attempt is first made to allocate the memory block required from the DataFlowEngine's heap. If there is not a large enough contiguous block of storage on the heap, then a request will be made to the operating system to allocate more storage to the DataFlowEngine for the message flow. Once this is done, then this would lead to the DataFlowEngine's heap growing with the additional storage, and the message flow will use this extra storage.
When the message flow has completed its processing, then it issues a "free" on all its storage and these blocks will be returned to the DataFlowEngine's heap ready for allocation to any other message flows of this DataFlowEngine. The storage is never released back to the operating system, because there is actually no programmatic mechanism to perform such an operation. The operating system will not retrieve storage from a process until the process is terminated. Therefore the user will never see the size of the DataFlowEngine process decrease, after it has increased.
When the next message flow runs, then it will make requests for storage, and these will then be allocated from the DataFlowEngine heap as before. Therefore there will be a re-use within the DataFlowEngine's internal storage where possible, minimizing the number of times that the operating system needs to allocate additional storage to the DataFlowEngine process. This would mean there may be some growth observed on DataFlowEngine's memory usage which is of the size of the subsequent allocations for message flow processing. Eventually we would expect the storage usage to plateau, and this situation would occur when the DataFlowEngine has a large enough heap such that any storage request can be satisfied without having to request more from the operating system.

Back to top

9. What is memory fragmentation in a DataFlowEngine process?

As explained in the above question, at the end of each message flow iteration, storage is freed back to the DataFlowEngine memory heap ready for re-use by other threads. However, there are objects that are created within the DataFlowEngine that last the life of the DataFlowEngine and therefore reside at that point in the heap for that time. This leads to what is known as fragmentation and as a result reduces the size of contiguous storage blocks available in the DataFlowEngine when an allocation request is made. This means that DataFlowEngine process has the memory blocks for allocation but are fragmented to be allocated to requests made during message processing. In most of the cases, the requesters of storage require a contiguous chain of blocks in memory. Therefore, it is possible for a message flow to make a request for storage against the DataFlowEngine's heap that does not have enough free storage to satisfy the request for this contiguous chain of blocks, but the storage is fragmented, such that the contiguous block does not fit into any of the "gaps". In this situation, a request would have to be made to the operating system to allocate more storage to the DataFlowEngine so that this block can be allocated.

However, when unfreed blocks remain on the DataFlowEngine's heap then this will fragment the heap. This means that there will be smaller contiguous blocks available on the DataFlowEngine's heap. If the next storage allocation cannot fit into the fragmented space, then this will cause the DataFlowEngine's memory heap to grow to accommodate the new request.

This is why small increments may be seen in the DataFlowEngine even after it has processed thousands of messages. In a multi-threaded environment there will be potentially many threads requesting storage at the same time, meaning that it is more difficult for a large block of storage to be allocated.

For example,

Some message flows implement BLOB domain processing which may result in the concatenating of BLOBs. Depending on how the message flow has been written, this may lead to fragmentation of the message heap due to the fact that when a binary operation takes place such as concatenation, both the source and target variables need to be in scope at the same time.

Consider a message flow that reads in a 1MB BLOB and assigns this to the BLOB domain. For the purposes of demonstration, this ESQL will show a WHILE loop that causes the repeated concatenation of this 1MB BLOB to produce a 57MB output message. Consider the following ESQL :

DECLARE c, d CHAR;
SET c = CAST(InputRoot.BLOB.BLOB AS CHAR CCSID InputProperties.CodedCharSetId);
SET d = c;

DECLARE i INT 1;
WHILE (i <= 56) DO
  SET c = c || d;
  SET i = i + 1;
END WHILE;

SET OutputRoot.BLOB.BLOB = CAST(c AS BLOB CCSID InputProperties.CodedCharSetId);

As can be seen, the 1MB input message is assigned to a variable c and then this is also copied to d. The loop then concatenates c to d and assigns the result back to c on iteration. This means that c will grow by 1MB on every iteration. Since this processing generates a 57MB blob, one may expect the message flow to use around 130MB of storage. The main aspects of this are the ~60MB of variables in the compute node, and then 57MB in the Output BLOB parser which will be serialised on the MQOutput node.

However this is not the case. This ESQL will actually cause a significant growth in the DFE's storage usage due to the nature of the processing. This ESQL encourages fragmentation in the memory heap. This condition means that the memory heap has enough free space on the current heap, but has no contiguous blocks that are large enough to satisfy the current request. When dealing with BLOB or CHAR Scalar variables in ESQL, these values need to be held in contiguous buffers in memory.

Therefore when the ESQL SET c = c || d; is executed, in memory terms this is not just a case of appending the value of d, to the current memory location of c. The concatenation operator takes two operands and then assigns the result to another variable, and in this case this just happens to be one of the input parameters. So logically the concatenation operator could be written SET c = concatenate(c,d). This is not valid syntax but is being used to illustrate that this operator is like any other binary operand function. The value contained in c cannot be deleted until the operation is complete since c is used on input. Furthermore, the result of the operation needs to be contained in temporary storage before it can be assigned to c.

Back to top

10. How can I tell if the out of memory is caused due to the DataFlowEngine running out of JVM Heapsize or total process memory?

- When a DataFlowEngine reaches the JVM heap limitations, it typically generates a javacore, heapdump along with a java out of memory exception in the EG stderr/stdout files.
When the DataFlowEngine runs out of total memory, it may cause the DataFlowEngine to go down or the system to become un-responsive.
 

Back to top

11. Are there any useful references in the area of broker/execution group memory usage?

See the following references:

• http://www-01.ibm.com/support/docview.wss?uid=swg21179304
• https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/important_facts_about_garbage_collection_in_websphere_message_broker?lang=en 

Back to top

12. What should I do in a broker to process a very large message?

See the following references:

• http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/topic/com.ibm.etools.mft.doc/ac67176_.htm
• http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/topic/com.ibm.etools.mft.doc/ac20702_.htm
• http://www.ibm.com/developerworks/websphere/library/techarticles/0505_storey/0505_storey.html

Back to top

13. What is MQSI_THREAD_STACK_SIZE and do I need to set it?

MQSI_THREAD_STACK_SIZE
Purpose : For any given message flow, a typical node requires about 2KB of the thread stack space. Therefore, by default, there is a limit of approximately 500 nodes within a single message flow on the UNIX platform and 1000 nodes on the Windows platform. This limit might be higher or lower, depending on the type of processing being performed within each node. If a message flow of a larger magnitude is required, one can increase this limit by setting the MQSI_THREAD_STACK_SIZE environment variable to an appropriate value( broker must be restarted for the variable to be effective). This environment variable setting applies to brokers, therefore the MQSI_THREAD_STACK_SIZE is used for every thread that is created within a DataFlowEngine process. If the execution group has many message flows assigned to it, and a large MQSI_THREAD_STACK_SIZE is set, this can lead to the DataFlowEngine process requiring a large amount of storage for the stack. In WMB, it is not just execution of nodes that can cause a build up on a finite stack size. It follows from the same principles for any processing that leads to a large amount of nested or recursive processing and might cause extensive usage of the stack. Therefore, you may need to increase the MQSI_THREAD_STACK_SIZE environment variable in the following situations: a) When processing a large message that has a large number of repetitions or nesting. b) When executing ESQL that recursively calls the same procedure or function. This can also apply to operators. For example, if the concatenation operator was used a large number of times in one ESQL statement, this could lead to a large stack build up.

However, it should be noted that this environment variable applies to all the message flow threads in all the execution groups, as it is set at the broker level. For example, if there are 30 message flows and this environment variable is set to 2MB then that would mean that 60MB would be reserved for just stack processing and thus taken away from the DataFlowEngine memory heap. This could have an adverse effect on the execution group rather than yielding any benefits. Typically, the default of 1 MB is sufficient for most of the scenarios. Therefore we would advise that this environment variable NOT be set unless absolutely necessary.
Please refer to the following link for more information:
http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/topic/com.ibm.etools.mft.doc/ac55020_.htm  

Back to top

 

14. Are there any needs for modifying the system kernel parameters for WMB/IIB?

In WMB/IIB there are no suggested kernel settings for the tuning of an operating system. However, the WebSphere MQ and some database products do, and WMB/IIB runs under the same environment as these. Hence, its best to check and tune your environment as guided by these applications.

Back to top

 

15. How do you set the limit of total memory consumed by the DataFlowEngine process?

There is no functionality within the Broker product to set a maximum memory limit on an execution groups. Operating systems may offer such functionality and the user should look into the ways of doing this on HP-UX. However, it should be noted, if a DataFlowEngine limit is set to a value that it needs to exceed, then it will terminate when the request for storage is refused.

Back to top

Cross reference information

Segment	Product	Component	Platform	Version	Edition
Business Integration	WebSphere Message Broker	High CPU/Memory growth/System related issues	AIX, HP-UX, Linux, Solaris, Windows	7.0, 8.0	All Editions

Product Alias/Synonym

WMB MB WebSphere Message Broker IBM Integration Bus IIB IBMIB MQ Integrator WBIMB WBI-MB MQSI WMQI