Which of the following attributes in the Monitoring tab for a JDBC connection pool in the Administrative console tell us how many clients are currently waiting for a connection?
a. Waiters high
b. Waiters
c. Connections high
d. Clients
e. Wait seconds high
Choice B is correct. JDBC subsystem resources can also be monitored via the Administration Console. The Monitoring tab for a JDBC connection pool allows you to access a table listing statistics for the instances of that pool. These attributes provide important information for managing client database access.
The Waiters High field indicates the highest number of clients waiting for a connection at one time. The Waiters field tells you how many clients are currently waiting for a connection. The Connections High field indicates the highest number of connections that have occurred at one time. The Wait Seconds High field tells you the longest duration a client has had to wait for a database connection. These attributes allow you to gauge the effectiveness of the current configuration in responding to client requests.
The MaxPostTimeSecs attribute set in the Administration console under Servers or virtual hosts section corresponds to which of the following?
a. The amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST.
b. The total amount of time that WebLogic Server spends receiving HTTP POST data.
c. The time spent by WebLogic server to post data to other servers in the cluster.
d. The number of bytes of data received in a POST from a single request.
Choice B is correct. Web servers may face denial-of-service attacks, which is usually carried out by sending huge amounts of data in an HTTP POST method. You can set three attributes in WebLogic Server that help prevent this type of attack. These attributes are set in the console, under Servers or virtual hosts. You can limit the amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST by setting the attribute PostTimeoutSecs.
The MaxPostTimeSecs attribute limits the total amount of time that WebLogic Server spends receiving post data. If this limit is triggered, a PostTimeoutException is thrown and a message is sent to the server log. MaxPostSize attribute limits the number of bytes of data received in a POST from a single request. If this limit is triggered, a MaxPostSizeExceeded exception is thrown and a message is sent to the server log.
How does sorting on message priority work?
First, you need to add a key to the destination (by default, they are not sorted), choosing JMSPriority as the key. If you want 0 to be your highest priority, make the key ascending. If you want 9 to be the highest priority, make the key descending.
Second, the priority must be set using either the producer or on the send, not the message.
Third, the priority sorting only comes into play if there are multiple messages waiting on the queue. If the receiver is always caught up with the sender, then the messages will be processed in the order in which they come in.
How do I get a thread dump to help track down a problem?
Ways to get a thread dump:
* Try running this from the command line (after running the setEnv script in /bea/wlserver6.1/config/mydomain/):
java weblogic.Admin -url t3://localhost:7001 THREAD_DUMP
* On Windows, from the console window, enter Ctrl+Break.
* On UNIX, signal the server using kill -3.
How do I manage a queue to view and delete specific messages?
Write a program that uses a QueueBrowser. Then delete specific messages by using a selector with the message identifier as in the following example:
String selector = "JMSMessageID = '" + message.getMessageID() + "'";
Keep in mind that the queue browser is a not a "live" view of the queue. It is a snap-shot.
Why do I get an exception when trying to find a connection factory?
The exception is usually something like java.io.InvalidClassException or java.lang.NoClassDefFoundError.
Make sure weblogic.jar is in the CLASSPATH of the client. Also make sure you have the correct Java run-time jar files included (i.e., you might need rt.jar).
What precautions should I take when I use blocking receive() calls?
If your application design requires messages to be received synchronously, we recommend using one of the following methods listed in order of preference:
* Pass a timeout value as an argument to the 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.
* Use the 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 wait().
Note: Use of this option should be minimized, as it may deadlock a busy server.
* Ensure that more threads are configured than the number of possible simultaneous blocking receive() calls.
What is the NO_ACKNOWLEDGE acknowledge mode used for?
The 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. v 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.
Note: You should avoid using this mode if your application cannot handle lost or duplicate messages. Duplicate messages may be sent if an initial attempt to deliver a message fails.
In addition, we do not recommend that this acknowledge mode be used with persistent messaging, as it implies a quality of service that may be too low for persistent messaging to be useful.
When should I use multicast subscribers?
Multicasting enables the delivery of messages to a select group of hosts that subsequently forwards the messages to multicast subscribers. The benefits of multicasting include:
* Near real-time delivery of messages to host group.
* High scalability due to the reduction in the amount of resources required by the JMS server to deliver messages to multicast subscribers.
Note: Multicasting is only supported for the Pub/sub messaging model.
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.
Multicast messages are not guaranteed to be delivered to all members of the host group. For messages requiring reliable delivery and recovery, you should not use multicasting.
When should I use server session pools and connection consumers?
WebLogic JMS implements an optional JMS facility for defining a server-managed pool of server sessions. This facility enables an application to process messages concurrently. A ConnectionConsumer object uses a server session to process received messages. If message traffic is heavy, the connection consumer can load each server session with multiple messages to minimize thread context switching. Multiple connection consumers can share server sessions in a server session pool.
To learn how to use the connection consumers within an application, see the section Processing Messages Concurrently in Programming WebLogic JMS, or the javax.jms.ConnectionConsumer javadoc.
Note: Server session pools can also be implemented using Message Driven Beans. Using MDBs is preferable to using server session pools - see the answer to the question, "How do server session pools and Message Driven Beans compare?" For information on using message driven beans to implement server session pools, see Programming WebLogic Enterprise JavaBeans.
No comments:
Post a Comment