I assume that when the number of incoming messages (to the pub/sub server) is very high, the messages will get batched befor getting delivered to subscribers. So I wanted to prioritize message delivery based on their urgency. Of course, messages in the batch will be only those that the server was not able to send in time.
I had considered your design of using 2 MDBs with the first one setting JMSPriority levels of the messages, but there are only 0-9 prority levels, and also, in my case priorities are to be set comparatively (based on the "deadline" field specified in the messages), so this solution does not seem to completely solve my need. Any way, thank you (including Zerbe John) for the kind suggestions, Jingwen ---- Original message ---- >Date: Tue, 3 Jan 2006 23:29:52 +0100 >From: Johan Eltes <[EMAIL PROTECTED]> >Subject: Re: Message-Driven Bean OnMesssage() etc >To: [email protected] > >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: [email protected] >> 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: [email protected] >>> >>> 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: [email protected] >>>>> >>>>> 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". =========================================================================== 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".
