130.Does the WebLogic JMS server find out about closed or lost connections,  
      crashes, and other problems and does it recover from them?
Yes, but how it does this depends on whether a Java client crashes or WebLogic Server crashes, as follows:

• If a Java client crashes then the JMS server will clean up all the outstanding server-side resource from the crashed client JVM, such as:
• JMS connection(s) from the crashed client JVM
• JMS temporary destination(s) created under the above JMS connection(s)
• JMS session(s) created under the above JMS connection(s)
• JMS client(s) created under the above JMS session(s) (connection consumer and regular consumer)
• JMS browser(s) created under the above session(s)
• JMS producer(s) created under the above session(s)
• If WebLogic Server crashes and it is the front-end to the JMS server, then:
• A JMS client will lose all the server-side resources listed above.
• The client's javax.jms.ExceptionListener.onException(...) will be called (if javax.jms.JMSConnection.setExceptionListener is set) with a LostServerException, which extends JMSException.
• If WebLogic server crashes and it is a back-end to the JMS server, then:
• A JMS client may partially lose some of the server-side resources listed above (only the resource on the crashed server, such as JMS temporary destination(s), JMS client(s) and JMS browser(s).
• The client's javax.jms.ExceptionListener.onException(...) will be called (if weblogic.jms.extensions.WLSession.setExceptionListener is set) with a ConsumerClosedException, which extends JMSException.

131.What Is the Java Message Service?
An enterprise messaging system enables applications to communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.
The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. Specifically, JMS:

• Enables Java applications sharing a messaging system to exchange messages
• Simplifies application development by providing a standard interface for creating, sending, and receiving messages

132.How many Messaging Modules are available in Weblogic?
JMS supports two messaging models: point-to-point (PTP) and publish/subscribe (pub/sub). The messaging models are very similar, except for the following differences:

• PTP messaging model enables the delivery of a message to exactly one recipient.
• Pub/sub messaging model enables the delivery of a message to multiple recipients.

133.Explain about Point-to-Point Messaging?
The point-to-point (PTP) messaging model enables one application to send a message to another. PTP messaging applications send and receive messages using named queues. A queue sender (producer) sends a message to a specific queue. A queue receiver (consumer) receives messages from a specific queue.
134.Explain about Publish/Subscribe Messaging?
The publish/subscribe (pub/sub) messaging model enables an application to send a message to multiple applications. Pub/sub messaging applications send and receive messages by subscribing to a topic. A topic publisher (producer) sends messages to a specific topic. A topic subscriber (consumer) retrieves messages from a specific topic.
135.Explain about Message Persistence?
As per the “Message Delivery Mode” section of the JMS Specification, messages can be specified as persistent or non-persistent:

• A persistent message is guaranteed to be delivered once-and-only-once. The message cannot be lost due to a JMS provider failure and it must not be delivered twice. It is not considered sent until it has been safely written to a file or database. WebLogic JMS writes persistent messages to a WebLogic persistent store (disk-base file or JDBC-accessible database) that is optionally targeted by each JMS server during configuration.
• Non-persistent messages are not stored. They are guaranteed to be delivered at-most-once, unless there is a JMS provider failure, in which case messages may be lost, and must not be delivered twice. If a connection is closed or recovered, all non-persistent messages that have not yet been acknowledged will be redelivered. Once a non-persistent message is acknowledged, it will not be redelivered.

136.Topics vs. Queues?
Surprisingly, when you are starting to design your application, it is not always immediately obvious whether it would be better to use a Topic or Queue. In general, you should choose a Topic only if one of the following conditions applies:

• The same message must be replicated to multiple consumers.
• A message should be dropped if there are no active consumers that would select it.
• There are many subscribers, each with a unique selector.

It is interesting to note that a topic with a single durable subscriber is semantically similar to a queue. The differences are as follows:

• If you change a topic selector for a durable subscriber, all previous messages in the subscription are deleted, while if you change a queue selector for consumer, no messages in the queue are deleted.
• A queue may have multiple consumers, and will distribute its messages in a round-robin fashion, whereas a topic subscriber is limited to only one consumer.

137.Asynchronous vs. Synchronous Consumers?
In general, asynchronous (onMessage) consumers perform and scale better than synchronous consumers:

• Asynchronous consumers create less network traffic. Messages are pushed unidirectionally, and are pipelined to the message listener. Pipelining supports the aggregation of multiple messages into a single network call.

Note: In WebLogic Server, your synchronous consumers can also use the same efficient behavior as asynchronous consumers by enabling the Prefetch Mode for Synchronous Consumers option on JMS connection factories

• Asynchronous consumers use fewer threads. An asynchronous consumer does not use a thread while it is inactive. A synchronous consumer consumes a thread for the duration of its receive call. As a result, a thread can remain idle for long periods, especially if the call specifies a blocking timeout.
• For application code that runs on a server, it is almost always best to use asynchronous consumers, typically via MDBs. The use of asynchronous consumers prevents the application code from doing a blocking operation on the server. A blocking operation, in turn, idles a server-side thread; it can even cause deadlocks. Deadlocks occur when blocking operations consume all threads. When no threads remain to handle the operations required unblocking the blocking operation itself, that operation never stops blocking.

138.What is a Distributed Destination?
A distributed destination is a set of destinations (queues or topics) that are accessible as a single, logical destination to a client. A distributed destination has the following characteristics:

• It is referenced by its own JNDI name.
• Members of the set are usually distributed across multiple servers within a cluster, with each destination member belonging to a separate JMS server.

139.Why Use a Distributed Destination?
Applications that use distributed destinations are more highly available than applications that use simple destinations because WebLogic JMS provides load balancing and failover for member destinations of a distributed destination within a cluster. Once properly configured, your producers and consumers are able to send and receive messages through the distributed destination. WebLogic JMS then balances the messaging load across all available members of the distributed destination. When one member becomes unavailable due a server failure, traffic is then redirected toward other available destination members in the set.
140.How many Types of Distributed Destinations are available?

• Uniform Distributed Destinations
• Weighted Distributed Destinations

Uniform Distributed Destinations
In a uniform distributed destination (UDD), each of the member destinations has a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.
Oracle recommends using UDDs because you no longer need to create or designate destination members, but instead rely on WebLogic Server to uniformly create the necessary members on the JMS servers to which a UDD is targeted. This feature of UDDs provides dynamic updating of a UDD when a new member is added or a member is removed.
Weighted Distributed Destinations
In a weighted distributed destination, the member destinations do not have a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.
Oracle recommends converting weighted distributed destinations to UDDs because of the administrative inflexibility when creating members that are intended to carry extra message load or have extra capacity (more weight). Lack of a consistent member configuration can lead to unforeseen administrative and application problems because the weighted distributed destination cannot be deployed consistently across a cluster.