WEBLOGIC SERVER FAQ(ANS)--9

weblogic interview questions and answers 

121.What is the use of “Destination” in JMS? How many types of “Destinations” are available in JMS?

• A destination is a lightweight object that is stored in JNDI.
• It is the target on a JMS server for sending or receiving messages.
• The JMS destination types are:
• Queue
• Topic

122.Explain about “Queue Destinations”?

In JMS point-to-point messaging, note the following:

• Clients communicate with a queue destination.
• Messages are distributed to consumers in a serial fashion (first in, first out).
• Each message is delivered only to a single consumer.

123.Explain about “Topic Destinations”?

In JMS publish/subscribe messaging, the following is true:

• Clients communicate with a topic destination.
• Messages are broadcast to all subscribers.
• A message can be saved until at least one subscriber has consumed it (“durable”).

124.Explain about Threshold and Quotas in JMS?

• A threshold and a quota can be set for the server and destination objects.
• A quota is a limit defined for the JMS-administered objects; it includes the following values:
• The maximum number of bytes that can be stored
• The maximum number of messages that can be stored
• A threshold is a limit that triggers message paging, flow control, and logged warnings, using:
• Upper and lower values for the number of bytes
• Upper and lower values for the number of messages

125.Difference between “Durable Subscribers and Subscriptions”?

• Durable subscribers register durable subscriptions for guaranteed message delivery even if the subscribers are inactive.
• A subscriber is considered active if the Java object that represents it exists.
• By default, subscribers are nondurable.
• Administrators configure:
• Where the messages are persisted
• Persistent connection factories and destinations

126.What is “Persistent Messaging”?  When to Use it?

• Persistent messaging permits messages in memory to be written out to a persistent store.
• Configure persistent messaging if:
• Development requires durable subscriptions (use durable subscribers in the application)
• You require that in-progress messages persist across server restarts

127.How will you Configuring a Durable Subscription in Weblogic?

• To configure durable subscriptions, an administrator must:
• Create and configure a JMS store
• Configure connection factories or destinations as persistent
• Associate the JMS store with the JMS server
• The JMS store can be configured to use either:
• A file store
• A JDBC store (a connection pool)

128.How a Durable Subscription Works?

• If a subscriber client is active, messages are delivered normally.
• When the client becomes active again, its ID is used to retrieve and redeliver messages.

129.What Node manager can do in Weblogic server?

You can use Node Manager to:

• Start, shut down, and restart an Administration Server
• Start, shut down, suspend, and restart Managed Servers
• Automatically restart the Administration and Managed Servers on failure
• Monitor servers and collect log data

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.