I see.
How do you know there isn't another yet not arrived message with a
higher priority? E.g. what is the trigger to start forwarding
messages? The priority field is probably your only option, if your
scenarioo is to always forward the highest-priority message available
on the queue at any given time. If the sender is out of your control
(which I guess implies that you determine the priority from the
payload), your safest, most scalable and most portable option (not
bad, ehe?) i probably to design two MDBs - one that consumes messages
from the destination, determines the priority and sends the message
as is to a new destination, but this time with the priority assigned
to the JMSPriority header field, which would allow a second MDB to
consume them in the order you needs to have them processed. But I
still have a hard time understanding you business case. Is the
original sender batching out messages and you need to process them in
priority within the batch? Some more background info would help.
/Johan
3 jan 2006 kl. 17.13 skrev Zerbe John W:
Are you using the JMSPriority field?
If so, you should be able to configure your message engine to
deliver the
messages in priority order rather than FIFO.
Using an "in memory" structure for this sort of thing (reordering
of messages)
is generally not a good idea.
If you ever need to scale up with multiple instances of the JVM on
potentially separate machines, you won't have access to the same
data structures from the separate instances.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED] Behalf Of Jingwen Jin
Sent: Sunday, January 01, 2006 12:42 PM
To: EJB-INTEREST@JAVA.SUN.COM
Subject: Re: Message-Driven Bean OnMesssage() etc
Hi Johan,
Thank you again for the generous response. I sent the following
text to Mark
Birenbaum on this list who responded me earlier. I'm posting the
message to the
group in the hope of getting feedbacks faster.
------------------------------------------------------------------
The reason I wanted to store incoming messages first is that I
wanted the
messages to get ordered based on their priority (determined by
their urgency and
importance), and have another thread or MDB deliver the messages in
order. So I
do need the two entities to share a common in-memory data
structure. Doing this
with regular threading is natural. But how can I simulate this
(sharing of a
common object) with multiple MDBs?
-------------------------------------------------------------------
Thanks, and Happy New Year,
Jingwen
---- Original message ----
Date: Sun, 1 Jan 2006 16:18:06 +0100
From: Johan Eltes <[EMAIL PROTECTED]>
Subject: Re: Message-Driven Bean OnMesssage() etc
To: Jingwen Jin <[EMAIL PROTECTED]>
Cc: EJB-INTEREST@JAVA.SUN.COM
If you have many MDB instances (e.g. threaded MDBs) simultaneously
pulling messages off the queue/topic, you could let each mdb instance
forward the message without creating a new thread. You wouldn't
usually need to do asynchronous *wihin* an MDB, since the MDB is
asynchronous itself. What exactly is it you need to achieve by
threading, in addition to what you get by having an MDB?
/Johan
1 jan 2006 kl. 01.06 skrev Jingwen Jin:
Hi, Thanks a lot for the suggestion. The fact that EJB does not
support
multi-threading surprised me. As I said, I wanted my MDB to store
incoming
messages in a data structure, and then have threads working on the
sending of
messages. How could such a task be achieved by using multiple
beans? More
details would be very helpful.
When google-ing, I found somebody commenting that multi-threading
would work
when separating the "multi threadedness" into a separate layer
outside of the
EJB layer. In such a case, a java job scheduler is needed to handle
the
scheduling. Have you or has anybody on the list used any scheduler
(such as the
Quartz scheduler)?
Thank you,
Jingwen
---- Original message ----
Date: Thu, 29 Dec 2005 09:29:03 +0100
From: Johan Eltes <[EMAIL PROTECTED]>
Subject: Re: Message-Driven Bean OnMesssage() etc
To: EJB-INTEREST@JAVA.SUN.COM
You are not allowed to create threads in an EJB.
One of the reasons is that transaction contexts are bound to
threads.
If you create a thread (most app servers will not let you), that
the
app server will not be able to manage it.
Would it be possible to have multiple MDBs (MDB pool size > 1)
instead of forking threads within your business logic?
/Johan
29 dec 2005 kl. 06.00 skrev Jingwen Jin:
I'm writing a pub/sub server that, on receiving an incoming
message,
stores it into a messageArray, and then creates a thread to
forward
messages in the array. The following code works ok if the
"forwardMessage"
method is called within onMessage(); messages get delivered.
But whenever I try to deliver the messages in messageArray using a
thread
as shown below, I get the following exception and messages
don't get
delivered:
ReplyMsgBean.forwardMessage: JMSException:
com.sun.messaging.jms.JMSException: [SEND_REPLY(9)] [C4036]: A
server
error occurred. : transaction failed: Unexpected Broker Exception:
[received message with Unknown Transaction ID -1: ignoring
message]
It looks like the server could not create the connection within
the
forwardMessage method.
I'd appreciate any suggestions.
Thanks,
Jingwen
---------------------------------
public class ReplyMsgBean implements MessageDrivenBean,
MessageListener {
...
public ReplyMsgBean() throws Exception {
messageArray = new ArrayList();
mft = new MessageForwardingThread();
mft.start();
}
public void ejbCreate() {
try {
Context initial = new InitialContext();
cf = (ConnectionFactory) initial.lookup(
"java:comp/env/jms/MyConnectionFactory");
} catch (Exception ex) {
logger.severe("ReplyMsgBean.ejbCreate: Exception: " +
ex.toString());
}
}
public void onMessage(Message inMessage) {
put the message into messageArray
}
private static void forwardMessage(TextMessage msg) {
...
Connection con = cf.createConnection();
Session ses = con.createSession(true, 0);
producer = ses.createProducer(topic);
producer.send(msg);
con.close();
}
final class MessageForwardingThread extends Thread {
...
public final void run() {
for every-message (msg) in messageArray
ReplyMsgBean.forwardMessage(msg);
}
}
==================================================================
==
==
=====
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message
"help".
===================================================================
==
======
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message
"help".
====================================================================
==
=====
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
======================================================================
=====
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
The information contained in this e-mail may be confidential and is
intended solely for the use of the named addressee.
Access, copying or re-use of the e-mail or any information
contained therein by any other person is not authorized.
If you are not the intended recipient please notify us immediately
by returning the e-mail to the originator.(17b)
======================================================================
=====
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".