WebLogic Server Frequently Asked Questions
A. There are numerous features that make WebLogic JMS unique. For a complete listing, see "Introduction to WebLogic JMS" in Programming WebLogic JMS.
A. Yes, there is a JMS C client available on the dev2dev Utility and Tools page, which has a downloadable
jmscapi.zip file that includes all the necessary files, as well as documentation and samples. This is not a supported product of BEA. However, if you have questions about this API you can post them to WebLogic JMS "weblogic.developer.interest.jms" newsgroup available on the BEA Newsgroup server.
A. Yes. WebLogic Server 8.1 provides a true J2EE application client. The WebLogic Server application client is provided as a standard client and a JMS client, packaged as two separate jar files—
/server/lib subdirectory of the WebLogic Server installation directory. Each jar is about 400 KB.
A. Refer to "Starting WebLogic Server and Configuring JMS" in the Programming WebLogic JMS for detailed instructions on starting WebLogic Server, accessing the Administration Console, and configuring a basic Weblogic JMS implementation.
A. A security policy is created when you define an association between a WebLogic resource and a user, group, or role. A WebLogic resource has no protection until you assign it a security policy. You can assign a security policy to any WebLogic JMS destination using the administration console.
Using the navigation tree, access your JMS destinations, which are under Services
browse() operations on the destination using the list box labeled Methods.
For instructions on how to set up security for all WebLogic Server resources, see "Securing WebLogic Resources".
A. Yes. For detailed information about using 5.1 connection factories in later versions of WebLogic JMS, see "Porting WebLogic JMS Applications" in Programming WebLogic JMS.
A. For a detailed explanation of this issue, refer to the JMS FAQ in the version 6.1 Frequently Asked Questions.
A. There are JMS Helper methods that allow you to locate JMS runtime and configuration JMX MBeans. There are also methods for dynamically creating and deleting JMS queue and topic destinations, as described in the JMS Helper Method Javadoc.
A. You must create a template on every
JMSServer where you want to be able to create temporary destinations. You can specify multiple JMSServer entries to support a Temporary Template and the system will load balance among those JMSServers to set up the temporary destination. See How do I start WebLogic Server and configure JMS? for a description about how to configure JMS. The resulting template definition looks something like the following:
After the template name, you can set any queue/topic attribute you want in the template (not including a JNDI name or topic multicast settings). The template is at the outer most level; that is, it should not be nested in your
Temporary destinations can only be consumed by the creating connection. Using topics, you create your temporary topic and subscribe to that temporary topic. If you want someone to publish to that temporary topic, you need to tell that someone what your topic is. You can send them a message and include your temporary topic in the JMSReplyTo field. The creator of the TemporaryTopic and the subscriber must be one in the same.
Temporary topics do not get names and cannot be subscribed to by other connections. When you create a temporary topic, the JMS provider returns a
javax.jms.Topic. You then need to advertise that topic to other parties (those who want to publish to the topic), putting it in your
JMSReplyTo field so that they can respond. In general, no one else can subscribe to the topic. You advertise the topic any way you want. Topics are Serializable (or in our case, Externalizable), which allows you to pass them around in RMI calls, through a file, binding it to a name in JNDI, etc. In short, create the topic at the subscriber side and advertise so that others can publish. You can get multiple subscribers on the same connection and get concurrent processing using multiple sessions.
For more information about using temporary destinations, see "Using Temporary Destinations" in Programming WebLogic JMS.
A. BEA's dev2dev Web site contains a "JMS Statistics View" program to print JMS statistics based on run-time MBeans. Also, there are JMS Helper methods that allow you to access run-time statistics for JMS connection, destination, consumer, and producer MBeans, as described in the JMS Helper Method Javadoc.
A. No. Each JMS server must have its own unique persistent store. Two file-based JMS persistent stores may share the same directory, but their messages will be stored in different files. In this case, the filenames will contain different prefixes.
Two JDBC-based JMS persistent stores may share the same database, but they must be configured to use a different Prefix Name which will be prepended to the database tables. For more information on configuring the JDBC Prefix Name, see "Using Prefixes With JMS JDBC Stores" in the Administration Console Online Help. If they are configured with the same Prefix Name, persistent messages will be corrupted and/or lost.
A. The JMS database can be any database that is accessible through a JDBC driver. For a list of drivers that WebLogic JMS detects, see "JMS JDBC Store Tasks" in the Administration Console Online Help.
A. If your JDBC driver is not included in the list of drivers in the question about JDBC databases supported by WebLogic JMS, then the tables required by JMS must be created manually. Follow the procedures in JDBC Database Utility in Programming WebLogic JMS to manually create the database tables for the JDBC store.
Note: WebLogic Server only guarantees support for the JDBC drivers listed in "JMS JDBC Stores Tasks" in the Administration Console Online Help. Support for any other JDBC driver is not guaranteed.
A. The procedures for removing and regenerating the JDBC store tables or creating the database tables manually are described in detail in JDBC Database Utility in Programming WebLogic JMS.
config.xmlfile should contain a line of the form
DefaultDeliveryMode mode on connection factory in the
config.xml file to persistent (the
QueueSender.setDeliver/send overrides this value). Similarly, for topics, you would set this via the
See the question, How do I start WebLogic Server and configure JMS? for a description of how to configure JMS.
A. The are a number of similarities and differences between file stores and JDBC stores. For a complete listing, see "JMS Stores Tasks" in the Administration Console Online Help.
A. It is very important when using distributed topics with non-durable subscribers. This is because if the clocks between the servers become too far askew, there is a possibility that messages will not be delivered. Here's how this could happen: both the connection factory for the distributed topic and the distributed topic members will use their local system clock to see if a consumer is created after a message is published. Messages published to topics before consumers are created are not visible to consumers. There is always a race in any topic when the message is published before the consumer is created.
Distributed topics widen this race when the system clocks on the server instances hosting the connection factory or the distributed topic members are not in sync. For example, if your application creates short-lived, non-durable topic consumers, and a consumer is listening through a connection factory on ServerA, but the message is published to distributed topic member on ServerB, and the clocks from ServerA and ServerB are out of sync (more than the life of the topic consumer you have created), then that consumer will not receive the message sent due to the difference in the system clocks.
A. The byte and message maximum values are quotas - not flow control. Message quotas prevent a WebLogic JMS server from filling up with messages and possibly running out of memory, causing unexpected results. Unless the "Blocking Sends" feature has been implemented, when you reach your quota, JMS prevents further sends with a
ResourceAllocationException (rather than blocking). You can set quotas on individual destinations or on a server as a whole. For more information on configuring the "Blocking Sends" feature, see "Avoiding Quota Exceptions by Blocking Message Producers" in the Administration Console Online Help.
The thresholds are also not flow control - though they would be better suited to that application than the quotas. The thresholds are simply settings that when exceeded cause a message to be logged to the console to let you know that you are falling behind.
WebLogic JMS also has a flow control feature that enables a JMS server or destination to slow down message producers when it is becoming overloaded. Specifically, when a JMS server/destination exceeds its specified bytes or messages thresholds, it instructs producers to limit their message flow. For more information, see "Controlling the Flow of Messages on JMS Servers and Destinations" in the Administration Console Online Help.
Note: The messages maximum setting on a connection factory is not a quota. This specifies the maximum numbers of outstanding messages that can exist after they have been pushed from the server but before an asynchronous consumer has seen them; it defaults to a value of 10.
A. In version 6.x, you could establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers, as described in "Configuring WebLogic JMS Clustering" in the Programming WebLogic JMS. Each connection factory can be deployed on multiple WebLogic Servers, serving as connection concentrators. You could configure multiple JMS servers on the various nodes in the cluster—as long as the servers are uniquely named—and can then assign destinations to the various JMS servers.
For WebLogic JMS 7.0 or later, you can also configure multiple destinations as part of a single distributed destination set within a cluster. Producers and consumers are able to send and receive through a distributed destination. In the event of a single server failure within the cluster, WebLogic JMS then distributes the load across all available physical destinations within the distributed destination. For more information, see "Distributed Destination Tasks" in the Administration Console Online Help.
WebLogic JMS also takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments. This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. For more information, see "Configuring JMS Migratable Targets" in the Programming WebLogic JMS.
A. A system administrator can specify on which WebLogic Server(s) applications will run by specifying targets when configuring connection factories. Each connection factory can be deployed on multiple WebLogic servers. For more information on configuring connection factories or using the default connection factories, see "WebLogic JMS Fundamentals" in the Programming WebLogic JMS.
A. The procedures for recovering from a WebLogic Server failure, and performing a manual failover, including programming considerations, are described in "Recovering From a WebLogic Server Failure" in Programming WebLogic JMS.
javax.jms.ExceptionListener.onException(...)will be called (if
javax.jms.JMSConnection.setExceptionListeneris set) with a
LostServerException, which extends JMSException.
javax.jms.ExceptionListener.onException(...)will be called (if
weblogic.jms.extensions.WLSession.setExceptionListeneris set) with a
ConsumerClosedException, which extends JMSException.
A. There are two exception listeners that you can register. Sun Microsystems' JMS specification defines C
onnection.setExceptionListener that tells you if there is a problem with the connection. That means that all consumers under that connection are also in trouble. The reason you will get the connection exception is because the WebLogic server you connect to on the other side is dead or not responding or someone killed your connection via the Mbean interface.
However, for WebLogic Server JMS, you may have multiple sessions in a connection, with the sessions going to multiple backend servers. WebLogic Server has an extension for this called
WLSession.setExceptionListener that tells you if there is a problem with a session. For more information, see the JMS WLSession Javadoc.
A. J2EE is all about making the interfaces standard. WebLogic's implementation of the RMI specification uses a proprietary wire-protocol known as T3. Sun's reference implementation of RMI uses a proprietary protocol called JRMP. The fact is that WebLogic developed T3 because they needed a scalable, efficient protocol for building enterprise-class distributed object systems with Java.
While T3 is specific to WebLogic, your application code does not need to know anything about T3 so you should not worry about this. Externalize the "WebLogic-specific strings" (
PROVIDER_URL, INITIAL_CONTEXT_FACTORY, etc.) to a properties file (or somewhere) and you can make your code completely portable to where you only need change these in the properties file to get your code to run on another J2EE application server.
A. If you want to use HTTP tunneling (wrap every message in HTTP to get through a firewall), you need to add
TunnelingEnabled="true" into your
<Server> definition in the
config.xml file or check the appropriate box on the console. Then use a URL like
http://localhost:7001 instead of
Context.PROVIDER_URL when getting your InitialContext. If you want HTTP tunneling with SSL, use
https://localhost:7002 (where https uses HTTP tunneling with SSL and 7002 is the secure port that you configured). You will pay a performance penalty for doing this, so only use tunneling it if you really need to (i.e., need to go through a firewall).
A. Refer to "Simple Access to Remote or Foreign JMS Providers" in the Administration Console Online Help and the "Using Foreign JMS Providers with WebLogic Server" white paper (
jmsproviders.pdf) on the JMS topic page, for a discussion on integrating MQ Series, IBus MessageServer, Fiorano, and SonicMQ.
For example, a client can use a two-phase transaction to send a message from a queue on one JMS server (server A) to a queue on another JMS server (server B). Each server has a unique persistent store. When the transaction is committed, the message is made visible on server B. If the transaction rolls back, the message is put back on the queue on server A.
A. Usually this problem is caused by explicitly using a transacted session which ignores the external, global transaction by design (a JMS specification requirement). A transacted JMS session always has its own inner transaction. It is not affected by any transaction context that the caller may have.
A. When WebLogic JMS is used inside the server, JMS sessions may automatically be enlisted in the JTA transaction depending on the setting of various parameters. Prior to release 8.1, WebLogic JMS sessions would automatically be enlisted in the JTA transaction if either of the following two conditions were met:
When a WebLogic JMS connection factory is registered as a
resource-reference inside an EJB, servlet, or JSP, and the connection factory is looked up out of the
java:comp/env JNDI tree, then the EJB container checks to make sure that the appropriate flags are set for transaction enlistment. If the WebLogic JMS connection factory does not support automatic transaction enlistment, then the EJB container will throw an exception if a JMS session is used inside a transaction context. When used without a
resource-reference however, such as in the case of an EJB that looks up a JMS connection factory directly, without using
java:comp/env, then no checking takes place. If the JMS session is used outside a JTA transaction, then no enlistment takes place.
The default connection factory,
weblogic.jms.ConnectionFactory, does not support automatic transaction enlistment. If you desire this behavior, you must use the
weblogic.jms.XAConnectionFactory factory. (The legacy connection factories
javax.jms.TopicConnectionFactory support automatic transaction enlistment as well.)
For more information, see "Using JMS With EJBs and Servlets" in Programming WebLogic JMS.
javax.jms.TopicConnectionFactoryfactories, or if you define your own factory and set the UserTransactionsEnabled flag to True, the JMS session participates in the outer transaction, if one exists and the JMS session is not transacted.)
A. As per Sun Microsystems' JMS specification, when you are in a transaction, the
acknowledgeMode is ignored. If
acknowledge() is called within a transaction, it is ignored.
A. Whenever two resources (such as JMS and a database) participate in a transaction, the transaction becomes two-phase. The database driver you are using is not XA compatible and can't normally participate in a two-phase transaction. The solution is to either use an XA compatible driver, or to configure the
JDBCTxDataSource value to set
enableTwoPhaseCommit to true. The caveat for the latter is that this can lead to heuristic errors. If you don't want JMS to participate in the current transaction, see the question How can an application do a JMS operation and have it succeed, independent of the result of the transaction?.
A. No. WebLogic JMS is its own resource manager. That is JMS itself implements XAResource and handles the transactions without depending on the database (even when the messages are stored in the database). That means whenever you are using JMS and a database (even if it is the same database as the JMS messages are stored) then it is 2PC.
You may find it will aid performance if you ensure the connection pool used for the database work exists on the same server as the JMS queue—the transaction will still be two-phase, but it will be handled with less network overhead. Another performance boost might be achieved by using JMS file stores rather than JMS JDBC stores.
A. You cannot use a TX data source with JMS. JMS must use a JDBC connection pool that uses a non-XA resource driver (you can't use an XA driver or a JTS driver). Do not set the
enableTwoPhaseCommit option. JMS does the XA support above the JDBC driver.
A. Yes. WebLogic Server 6.1 or later fully implements the
XATopicSession methods. These methods are defined as optional in Sun Microsystems' JMS specification and are not part of the
A. For more information about what occurs when a message is rolled back or recovered, refer to "Managing Rolled Back, Recovered, Redelivered, or Expired Messages" in Programming WebLogic JMS.
Each time you suspend, you need to push the transaction onto a stack or list possibly with the message so you can process it or roll it back later. This solution is high overhead in that there can be a large build up of outstanding transactions. Note that transactions have timeouts and it may rollback on its own, which means you can get the message again (in a different transaction). Note also that there are some practical limits on the number of transactions you should leave outstanding. The default limit is something like 10000. Eventually you want to go back to your stack/list and commit/rollback the transactions. Note that transaction references (
javax.transaction.Transaction) are not Serializable.
A. Destinations are sorted as FIFO (first-in, first-out) by default; therefore, destination keys are used to define an alternate sort order for a specific destination. Destination keys can be message header or property fields. For a list of valid message header and property fields, refer to the "Message" section in Programming WebLogic JMS.
Destinations can be sorted in ascending or descending order based on the destination key. A destination is considered to be FIFO if a destination key is defined as ascending for the
JMSMessageID message header field, and LIFO (last-in, first-out) if defined as descending. The key defined for the
JMSMessageID header field, if specified, must be the last key defined in the list of keys. You can define multiple destination keys to sort a destination.
To create a destination key, use the Destination Keys node in the Administration Console. For more information, refer to "Destination Key Tasks" in the Administration Console Online Help.
A. Consider using the asynchronous pipeline for your message listeners to improve performance, as described in the "Asynchronous Message Pipeline" section of Programming WebLogic JMS.
A. Yes, durable subscribers require unique client identifiers. For more information on configuring durable subscribers using the connection factory's Client ID attribute, or by programming your application to set a client ID in its connection (by calling the
setClientID() connection method), see "Setting Up Durable Subscribers" in Programming WebLogic JMS.
A. Order is maintained between any producer and consumer for like delivery mode, sort order, and selector in the absence of a rollback or recover. There are no guarantees of order when multiple producers send to a single consumer or multiple consumers receive from multiple producers.
Order is generally maintained between a producer and a consumer. However, non-persistent messages can get ahead of persistent messages of a higher sort order (i.e., higher priority), can move ahead of each other and a recover or rollback puts messages that were already received back into the queue/topic, which affects order.
Most messaging systems (including WebLogic JMS) maintain order between a producer and a destination and then order between the destination and the consumer. So, once things arrive at the destination, the order does not change.
Finally, the asynchronous pipeline that is supported in WebLogic JMS affects the ordering. By default there can be as many as ten outstanding messages pushed out from the server to an asynchronous client that have not been seen by the client yet. If the asynchronous consumer is "caught" up, these messages will not be sorted. Destination sorting does not occur in the pipeline. If a destination is sorted by priority, and a new message comes in of higher priority than those messages already in the pipeline, it will not leap ahead in the pipeline, it will become first in the destination. The size of the pipeline is configurable; see the MessagesMaximum setting on the connection factory used. If you want real priority sorting, change the maximum number of messages on the factory to one. For more information, see the "Asynchronous Message Pipeline" section of Programming WebLogic JMS.
A. In WebLogic JMS 8.1 message ordering can be maintained to single consumers on a queue or topic subscription - even in the event of rollbacks and recoveries, as described in "Ordered Redelivery of Messages" in Programming WebLogic JMS.
A. Yes, although the JMS specification does not define the behavior here.
A. No. An alternative is to create a topic with a single durable subscription because a durable subscription may only have one consumer associated with it. The only drawback is that selectors would no longer work the same as they do with queues. Changing the selector on a durable subscription "resets" the subscription as per Sun Microsystems' JMS specification, causing all messages currently in the subscription to be deleted.
A. These methods are for vendor use only. The message values are overwritten on each send/publish. You should use the equivalent methods on the
TopicPublisher to set these values (i.e.,
setTimeToLive). Check to see that these values are not being overridden by the optional template configuration override values.
A. The rules for multi-threading are described in section 2.8 of the JMS specification, with additional language in sections 4.4.6 on session usage, 4.4.9 on using multiple sessions, and 4.4.17 on concurrent message delivery. In a nutshell, it states that JMS sessions are single-threaded. Consequently, if multiple threads simultaneously access a session or one of its consumers or producers the resulting behavior is undefined. In addition, if multiple asynchronous consumers exist on a session, messages will be delivered to them in series and not in parallel.
To take advantage of multiple threads with JMS, use multiple sessions. For example, to allow parallel synchronous receive requests, design the application so that only one consumer may be active per session and use multiple sessions.
A. If you want to listen to N topics, using N subscribers and N sessions gives you concurrency up to N simultaneous threads of execution provided you have that many threads to work with. N subscribers and 1 session serializes all subscribers through that one session. If the load is heavy they may not be able to keep up without the extra threads. Also, if you are using
CLIENT_ACKNOWLEDGE, N sessions gives you N separate message streams that can be individually recovered. Having 1 session crosses the streams giving you less control.
A. The synchronous
receive() method blocks until a message is produced, the timeout value, if specified, elapses or the application is closed. We strongly recommend that you avoid using blocking
receive() calls on the server side because a synchronous
receive() call consumes resources for the entire duration that the call is blocked.
receive()method and set it to the minimum value greater than zero, that is allowed by the application to avoid consuming threads that are waiting for a response from the server.
receiveNoWait()method which returns the next message or a null value if no message is currently available. In this case, the call does not block. The servlet should provide a way to return to or reschedule the request, without calling
NO_ACKNOWLEDGE acknowledge mode indicates that received messages do not need to be specifically acknowledged which improves performance, but risks that messages are lost. This mode is supported for applications that do not require the quality of service provided by session acknowledge and that do not want to incur the associated overhead.
Messages sent to a
NO_ACKNOWLEDGE session are immediately deleted from the server. Messages received in this mode are not recovered and, as a result, messages may be lost and/or duplicate message may be delivered if an initial attempt to deliver a message fails.
For an example of when multicasting might be useful, consider a stock ticker. When accessing stock quotes, timely delivery is more important than reliability. When accessing the stock information in real-time, if all, or a portion, of the contents is not delivered, the client can simply request the information be resent. Clients would not want to have the information recovered in this case because by the time it is redelivered it would be out-of-date.
A. WebLogic JMS implements an optional JMS facility for defining a server-managed pool of server sessions. However, session pools are now used rarely, as they are not a required part of the J2EE specification, do not support JTA user transactions, and are largely superseded by message-driven beans (MDBs), which are simpler, easier to manage, and more capable.
A. If you wish to issue the
close() method within an
onMessage() method call, the system administrator must select the Allow Close In OnMessage
close() method within an
onMessage() method call, the call will hang.
close()method is being called).
When you close a connection, all associated objects are also closed. You can continue to use the message objects created or received via the connection, except the received message's
acknowledge() method. Closing a closed connection has no effect.
A. This topic is covered in news://firstname.lastname@example.org. The sample code does not cleanup properly at shutdown. You can use a shutdown class that does something like the following:
Load-on-start servlets can provide a nice solution to provide both initialization and cleanup. For more information, refer to What is the standard way to create threads, do initialization, etc. within the application server?.
Outside of a MDB, you can do this by using the same Connection or Session that the
onMessage() is part of. When you create your message listener, you pass a session into your constructor. Then you have access to the session in your
onMessage() method and are able to make synchronous - not asynchronous - calls from within the
onMessage() method. Do not use another Session that is servicing another
onMessage(), because that would multi-thread the Session, and Sessions do not support multi-threading.
However, when using this technique outside a MDB, there is no way to guarantee that the receipt of the message by the MessageListener, and the send of the new message, happen as part of the same transaction. So, there can be duplicates or even lost messages. For example:
publish()and the acknowledge fails for whatever reason (network or server failure), then you will see the message again and will end up publishing twice (possible duplicate semantics). You can try to keep track of sequence numbers to detect duplicates, but this is not easy.
publish(), you get at-most-once transaction semantics. If the
publish()fails, you don't know if the failure occurred before or after the message reached the server.
If you require exactly-once transactional semantics using
onMessage(), then you must use transactional MDBs. In this case, the
onMessage() method for a transactional MDB starts the transaction and includes the WebLogic JMS message received within that transaction. Then, you must ensure that the
publish of the new message is part of the same transaction as the receipt of the message.
In WebLogic Server 8.1, you can guarantee that this happens by using a connection factory that you get from a
resource-reference defined for the MDB. For detail instructions on how to accomplish this, see "Using JMS With EJBs and Servlets" in Programming WebLogic JMS. By using a
resource-reference, you also get automatic pooling of the JMS Connection, Session, and MessageProducer objects, and the transaction enlistment will happen automatically regardless of whether you use WebLogic JMS or another JMS provider, as long as the JMS provider supports XA.
In earlier versions of the product, WebLogic JMS would automatically enlist itself with the current transaction if the UserTransactionsEnabled or XAServerEnabled flag was set on the connection factory. However, prior to release 8.1, the server will not pool any JMS objects or automatically enlist a foreign JMS provider in the transaction. In these earlier versions, you may want to cache JMS objects yourself. For more information, see How do I create a producer pool?.
A. For instructions on how to accomplish this, see "Using JMS With EJBs and Servlets" in Programming WebLogic JMS. For a detailed code sample, see the "Appendix A: Producer Pool Example" section in the "WebLogic JMS Performance Guide" white paper (
WeblogicJMSPerformanceGuide.zip) on the JMS topic page.
A rolled back message remains pending until the transaction actually rolls back. Rolling it back multiple times does not cause double counting, nor does an exception that set a transaction as rollbackOnly followed by an actual rollback.
A. WebLogic Server JMS does not know what to do with foreign destinations that it runs into. This issue has been discussed with Sun and the specification does not clearly define destinations well enough for vendors to interoperate at that level. They agree that it is sufficient not to handle foreign destinations preferably in such a way that sending/receiving still work. For WebLogic JMS, if you do a
setJMSdestination (you should not because it is only for the provider to set it) with a foreign destination, it gets ignored (set to null). Similarly, if you do a
setJMSReplyTo for a foreign destination, WebLogic JMS will ignore it (set it to null).
A. Threads should generally not be created by the user directly is because things may not work correctly. User-created threads do not have some of the thread-local variables pre-set by WebLogic when it creates it's own execute threads, the associated transaction context, or the environment such as the proper class loader. The WebLogic-specific way of doing this is with a startup class or using the WebLogic Time Services. The portable way to do this is to define a load-on-startup servlet, doing the initialization in the
init() method and the cleanup in the
destroy() method. The servlet itself does nothing. This approach also allows for undeploy/redeploy of the application without restarting the server, including proper cleanup/initialization each time. It also providers more dynamic management of the dependent classes without restarting the server.
A. This is a JNDI implementation issue. JNDI uses the dots to build a directory-like structure. A given element cannot be both a node and a leaf in the tree. In this example, B is used as a leaf off of A, but then is used as a node off of which C is a leaf.
A. For instructions and samples about using XPATH syntax with WebLogic JMS, see "Defining XML Message Selectors Using the XML Selector Method" in Programming WebLogic JMS.
WeblogicJMSPerformanceGuide.zip) on the JMS topic page.
A. Yes, with one caveat. You may not add new subscribers/consumers to a session if it already has active async consumers. Sessions must only be accessed single-threaded as per the JMS Specification. If you feel you need to do this, create a new Session and add it to that one instead.
You can add receivers to a session that is part of a started connection. However, a receiver in itself is not asynchronous. You need a listener to make it asynchronous. The first creation of a receiver is always safe. If you then add a listener for that first receiver, you have to worry for any future receivers in that same session. You can create new sessions and the first receiver for that session with no worries.
Once you want to create a second receiver in a session, if the first receiver has a
MessageListener, you have to take care to make sure there are no other threads of execution in that session. You can do this by stopping the connection or actually creating your receiver from the
onMessage routine of the first receiver.
A. Quotas can be used to help this situation. Your sender will then receive
ResourceAllocationExceptions and the server will stay up. In release 8.1 or later, senders can be configured to block waiting for space rather than receive
ResourceAllocationExceptions. For more information, see "Avoiding Quota Exceptions by Blocking Message Producers" in the Administration Console Online Help.
You can also use the Message Paging feature, which saves memory by swapping messages out from virtual memory to a dedicate paging store when message loads reach a specified threshold. JMS message paging saves memory for both persistent and non-persistent messages, as even persistent messages cache their data in memory. For more information, see "Paging Out Messages To Free Up Memory" in the Administration Console Online Help.
A. Think of a connection as a single physical connection (a TCP/IP link). A session is a means for producing and consuming an ordered set of messages. Creating a connection is generally expensive. Creating a session is less expensive. Generally people use one connection and share across all the threads with each thread having its own session. If you have thread groups and need to start/stop/close the resources for a given group, one connection per group is good. A group can have exactly one thread.
A. No. Once you instantiate the consumer the selector is fixed at the time that the consumer is created. Changing the selector is like removing the current consumer, removing all associated messages and then creating a new one.
A. Due to a limitation in the JMS specification, asynchronous messages can become deadlocked if the
close() method of a session is inside a user-synchronized block. To resolve this, you must move the
close() method outside the user-synchronized block. For example:
connection.close() method is closed, another message can be delivered to the
onMessage routine by the
main() method thread owns the monitor lock for the
CloseTest method. Before the
onMessage() method of the
CloseTest class fires, JMS sets
INLISTENER as the state for the session in
JMSSession (the JMS specification says that the
close() method must wait for the
onMessage routine), so that the
main() method thread can wait for the
onMessage routine to complete.
A. The message-driven bean is a stateless component that is invoked by the EJB container as a result of receiving messages from a JMS queue or topic. It then performs business logic based on the message contents, effectually freeing you from any JMS configuration and reconnection chores.
The message-driven bean model allows EJB developers to work with a familiar framework and set of tools, and also provides access to the additional support provided by the container. The goal of the message-driven bean model is to assure that developing an EJB that is asynchronously invoked to handle the processing of incoming JMS messages is as easy as developing the same functionality in any other JMS
One of the main advantages of using message-driven beans in place of the standard JMS
MessageListener is that a JTA transaction can be started for you automatically and the received message will be part of that transaction. In this case, other operations can be infected with the same JTA transaction such as database operations. This is the only way to infect a message from an asynchronous consumer and another JTA operation with the same transaction.
For more information on message-driven beans, see "Designing Message-Driven Beans" in Programming WebLogic Enterprise JavaBeans.
A. For a queue, multiple JMS Sessions are created on each server instance where the MDB is deployed. The number of sessions created is never greater than the
max-beans-in-free-pool setting in the MDB's deployment descriptor. JMS then delivers messages in parallel to the MDB instances as it would for any other kind of message listener. If a MDB is deployed to multiple servers in a cluster, Sessions are created for each MDB instance on each server.
For a topic, however, one topic consumer is used to pass out messages to multiple threads to get concurrency, while producing only a single copy of each message. If multiple MDBs are deployed to listen on the same topic, then each MDB will receive a copy of every message. Therefore, when a MDB is deployed to multiple servers and it listens to a topic, each server will receive its own copy of each message. So, if you want a message to be processed by exactly one MDB, you should use a queue.
A. Yes. You have no JMS context inside the MDB so you will need to establish a connection, session and producer yourself. One option is to do this every time you come into the
onMessage routine for the MDB. This is sufficient if the message rate is relatively low. The second option is to establish the necessary objects in
ejbActivate(). Note that the objects are not serializable so they can't be passivated for a stateful session bean or an entity bean. When the EJB deactivates, you need to close the associated objects. The third option is that you could build up a JMS connection/sender session pool within a startup class complete with your own synchronization and blocking to get a connection. There is an example of this in the question Is it possible to send or receive a message from within a message listener?.
For more information, see "Using JMS With EJBs and Servlets" in Programming WebLogic JMS.
A. The durable subscription is created when the MDB is deployed for the first time. The durable subscription is not deleted when the MDB is undeployed or deleted. This means that once the MDB has been deployed once, messages will continue to accumulate on the subscription, even if the MDB is undeployed or deleted. So, when an MDB is retired from service, you should delete the durable subscription to prevent a build-up of messages. You can use the administration console to do this, or you can write a standalone program using the Java API that calls
unsubscribe on the durable subscription.
A. Yes. In WebLogic Server 7.0 or later, you can deploy an MDB that supports container-managed transactions against a foreign JMS provider. If the MDB is configured with a "transaction-type" attribute of "Container" and a "trans-attribute" of "Required", then WLS will use XA to automatically enlist the foreign JMS provider in a transaction. (See the next question for an example of an MDB that uses container-managed transactions.)
If the foreign JMS provider does not support XA, then you cannot deploy an MDB that supports container-managed transactions with that provider. Furthermore, if the JMS provider does support XA, you must ensure that the JMS connection factory that you specify in the
weblogic-ejb-jar.xml file supports XA—each JMS provider has a different way to specify this.