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.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
