Are foreign destinations handled within foreign JMS
messages?
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 JMS 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 Server 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 Server JMS will ignore it
(set it to null).
What is the standard way to create threads, do
initialization, etc. within the application server?
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.
How many messages are sent across the network for
processing topic messages? If there are three
subscribers for a message, for example, one of which
with a selector that does not match, how many messages
are sent?
In WebLogic JMS 6.1, when all three consumers are in the
same session, we send one copy of the message across the
network for all subscribers that are not
flow-controlled. Once a consumer is flow-controlled for
not acknowledging enough messages, no messages are sent
until flow control is eased. So, the answer is usually
one, but may be two. The selection is done on the server
side so a subscriber that doesn't match doesn't have to
discard anything.
What should an XPATH selector look like?
The following is an example of an XPATH selector. Pay
careful attention to the use of double and single
quotes.
String selector =
"JMS_BEA_SELECT('xpath', '/recipient/transport/text()')
=
'email'";
tsubscriber = tsession.createSubscriber(topic, selector,
false);
JMS_BEA_SELECT is a built-in function in WebLogic Server
JMS SQL syntax. You put it in your selector string when
you create a consumer. Note the use of single quotes
around xpath, the XML tab, and the string value.
How do I handle request/response using JMS?
There are several approaches to handling
request/response processing with JMS.
* Use a temporary queue for each requestor and have the
response go back to that queue.
* Use the QueueRequestor class, which does the temporary
queue for you, and wait for the reply, as in the
following:
// create temporary queue for receiving answer
qrequestor = new QueueRequestor(qsession, queue);
TextMessage msg = qsession.createTextMessage();
TextMessage reply = (TextMessage) qrequestor.request(msg);
* Use a dedicated response topic or queue with message
selectors.
How do I put a message back on the queue for processing?
The following are several approaches:
* Use a transacted session, then rollback the session so
the message will go back to the queue.
* Use Session.CLIENT_ACKNOWLEDGE when creating a
session, then recover the session so the message will go
back to the queue.
* Use a JTA transaction, then rollback the transaction
so the message will go back to the queue.
Is it OK to add new sessions and subscribers to a Queue
or Topic Connection once it has been started?
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 spec. 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 started connection. 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.
What can I do when I get java.lang.OutOfMemoryError
because producers are faster than consumers?
Quotas can be used to help this situation. Your sender
will then receive ResourceAllocationExceptions and the
server will stay up. WLS 6.X does not support paging of
messages out of memory.
As of WLS 6.1 SP02 or later, you can use the Message
Paging feature, which can free up valuable virtual
memory during peak message load periods by swapping out
messages from virtual memory to persistent storage when
message loads reach a specified threshold.
Which of the following is NOT true about deploying EJBs
in the WebLogic Server?
a. The weblogic/config/examples/applications directory
acts as an automatic deployment directory for EJB 2.0
.jar files and EJB .jar deployment directories
b. The automatic redeployment feature of the WebLogic
Server can only redeploy an EJB's implementation
classes, you cannot redeploy an EJB's public interfaces
c. Before deploying a packaged jar file containing
uncompiled EJB classes and interfaces, we have to use
weblogic.ejbc on the packaged .jar file to generate
WebLogic Server container classes.
Choice C is correct because it is NOT true. A and B are
true about deploying EJBs in the WebLogic server. The
weblogic/config/examples/applications directory acts as
an automatic deployment directory for EJB 2.0 .jar files
and EJB .jar deployment directories. When you start
WebLogic Server, it automatically deploys any valid EJB
2.0 .jar files or .jar directories that reside in the
applications directory. WebLogic Server also checks the
contents of applications every ten seconds to determine
whether an EJB deployment has changed. If a deployment
has changed, it is automatically redeployed using the
dynamic deployment feature.
If you change the contents of a compiled EJB .jar file
in applications, WebLogic Server automatically attempts
to redeploy the .jar using the dynamic deployment
feature. Since the automatic redeployment feature uses
dynamic deployment, WebLogic Server can only redeploy an
EJB's implementation classes. You cannot redeploy an
EJB's public interfaces. You create compiled EJB 2.0
.jar files by Compiling your EJB classes and interfaces,
packaging the EJB classes and interfaces into a valid
.jar file and then Using weblogic.ejbc on the .jar file
to generate WebLogic Server container classes. An
uncompiled EJB .jar file has the same structure as a
compiled file, but you do not have to compile individual
class files and interfaces and you do not have to use
weblogic.ejbc on the packaged .jar file to generate
WebLogic Server container classes. So C is not true.
How do I debug WebLogic Server using Visual Cafe 4.1?
You can install VisualCafe Enterprise Edition 4.1 and
attach it to the server, pretty much as it worked for
3.X.
The following are steps for debugging using VC 4.1. You
may change the directory names as necessary.
1. Install it under D:\VisualCafeEE. No special options
are needed.
2. Install the license under C:\Program Files\Common
Files\WebGain Shared.
3. Start ddservices by selecting Start -> Programs ->
WebGain Studio Professional ->Visual Cafe Enterprise
Edition 4.1 -> Distributed Debugging Services -> Start
DD Services (Java2 - 1.3)
4. Start WebLogic Server using debugvm.exe instead of
java.exe.
cd D:\bea\wlserver6.1\config\mydomain
setEnv
edit startWebLogic.cmd
change "%JAVA_home%\bin\java" -hotspot -ms64m -mx64m to
\visualcafeEE\jdk13\bin\debugvm.exe
5. Run startWebLogic. It prints out some debugging
information.
6. Run VisualCafe - Start -> Programs -> WebGain Studio
Professional -> Visual Cafe Enterprise Edition 4.1 ->
Visual Cafe Enterprise Edition 4.1
7. From the File menu, select Attach to Process. If
everything is working correctly, you should see your
machine name.
8. Click the + sign to expand the tree and select your
running WebLogic Server.
How can I avoid asynchronous message deadlocks?
Due to a limitation in the JMS 1.0.2 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:
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
connection.close();
}
}
private void onMessage(Message message) {
synchronized (this) {
notify();
}
}
}
Before the connection.close() method is closed, another
message can be delivered to the onMessage routine by the
JMSProvider. 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.
Now when the onMessage routine tries to acquire the
monitor lock, it blocks waiting for the main() method
thread to give up, and the main() method thread is
waiting for the onMessage to be completed.
JMS also blocks when the close() method of a consumer is
done from an onMessage routine and the
allowCloseInOnMessage attribute is set to false in the
config.xml file.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
