Correct use of MessageDrivenBean?

Discussions

EJB design: Correct use of MessageDrivenBean?

  1. Correct use of MessageDrivenBean? (9 messages)

    I'm working on designing a webservice for creating PDFs from XSL:FO documents. Since some PDF generation may take a large ammount of time we are hoping to have the generation done asynchronously.

    I've been researching EJBs for the past week and have just recently been reading about MessageDrivenBeans. From what I've found it looks as though the onMessage method is called asynchronously so the client can continue on while a background proccess on the server proccesses the message. Would doing some SQL work for tracking job generation and doing the actual PDF generation be an appropriate use of a MDB?

    -Eric Dalquist
  2. Perfect scenario for you to use JMS solution. You don't need to wait for your PDF generation if you are using JMS. You just kick off the generation via a Message and your application can do something more important.

    -Shree
  3. Thank you for the confirmation!

    Now to figure out how to create a MDB that is called via a web service on OC4J.

    -Eric
  4. I'm working on designing a webservice for creating PDFs from XSL:FO documents. Since some PDF generation may take a large ammount of time we are hoping to have the generation done asynchronously.I've been researching EJBs for the past week and have just recently been reading about MessageDrivenBeans. From what I've found it looks as though the onMessage method is called asynchronously so the client can continue on while a background proccess on the server proccesses the message. Would doing some SQL work for tracking job generation and doing the actual PDF generation be an appropriate use of a MDB?-Eric Dalquist
    Eric,

    Thinking wildly. I would not use MDBs in your scenario. Reason: If you just want to asynchronously convert documents, why not have a batch that wakes up on a timer and converts the documents. Why do you want to flood with JMS messages?

    Perhaps, I am missing some key part of your thought process.

    -Sanjay.
  5. Reason: If you just want to asynchronously convert documents, why not have a batch that wakes up on a timer and converts the documents. Why do you want to flood with JMS messages? Perhaps, I am missing some key part of your thought process. -Sanjay.
    `
    Why not re-use a solution that is already available? Using a persistent queue will provide all the functionality that is needed in this scenario and has the advantage of not having to deal with all the nitty-gritty details. Ofcourse you can achieve the same functionality with writing the content of the request to a database or the file system, but you'll have to write more code to achieve the same goal.

    --
    Jeroen
  6. Why not re-use a solution that is already available? Using a persistent queue will provide all the functionality that is needed in this scenario and has the advantage of not having to deal with all the nitty-gritty details. Ofcourse you can achieve the same functionality with writing the content of the request to a database or the file system, but you'll have to write more code to achieve the same goal.--Jeroen
    May be I am dumb, but I still fail to understand why you need JMS, persistence, MDBs, network flodding with JMS messages etc. for a simple conversion routine to convert XSL:FO to PDF. Reuse is good as long as it is worth. I would not reuse something just because it exists if I am "reusing" only 5% of what it has to offer. I do not think anyone will "reuse" JBoss / Geronimo for a HTTP listener. Do we?

    -Sanjay.
  7. In fact, I would reuse Quartz enterprise Job scheduler for this purpose than an MDB solution from sourceforge. That has all I see in this scenario.

    Dumb,
    -Sanjay.
  8. I see your point but I don't see how the network traffic of adding the XSL:FO to a persistent queue (would probably have to be database or soemthing) is any more traffic than a single JMS message per request. One way or another the request with the XSL:FO needs to be put on a persistent queue. Is there really that much network overhead in JMS compaired to say JDBC or something similar?
  9. I see your point but I don't see how the network traffic of adding the XSL:FO to a persistent queue (would probably have to be database or soemthing) is any more traffic than a single JMS message per request. One way or another the request with the XSL:FO needs to be put on a persistent queue. Is there really that much network overhead in JMS compaired to say JDBC or something similar?
    Eric:

    NO. Not more than JDBC or so, until you start doing clustered MQ, which might become reality when you start having more requests. A Collaborative scheduler can do it much better. it is a question of 0 network traffic or >0 traffic - not the question of more or less. Just my 2 cents, because I have done such an app long back (7 years back - 1997) and the app is withstanding a 4 continent global deployment till date without much issues. I still cant believe a JMS solution can do that, may be it can, but by the time I reach that I would have got curses from my customer on the number of boxes I wanted him to buy for my solution :-).

    -Sanjay.
  10. I have an exact similar requirement and I want to process the request synchronously if the time taken is less than 1 minutel if the time taken is more than one minute then I want to process it asynchronously.

    Please see below

    I am having a situation where clients from a browser submits Http requests to generate reports. Typically the reports takes from 1 min to 20 minutes to run.
    In our current implementation, there is a servlet that gets the reporting request and processess synchronously.
    Some times we see the app hanging etc.

    So,I wanted to introduce messaging to this and decouple the client from the server.

    1. The servlet writes the report-request to a JMS queue
    2. There is a QueueReceiver which asynchronously reads the report request and sends a message back to another queue,
    which the servlet ( from step 1 )is reading. I am planning to use co-relation ids for identifying the response

    3. Now the servlet ( from step 1) will synchronously try to read with timeout ( if the report-request got processed quickly around 1 minute ). If it gets something in the queue with the co-relation id then it returns the report back. If id does not receive anything within a minute, then it throws back a message to the user saying that the request is being submitted in background.

    4. Mean while there is another MDB in background listening for messages from the same queue ( like Servlet in step 3). The idea is to have this MDB pickup response messages for which processing took longer than 1 minute.

    This way the client will have a better experience in that for short report-requests he will get synchronous response
    wheres as for longer requests he will be notified that the report is running in the background.

    Pl let me know what is the best way to implement this scenario. Can I use distributed destinations and have one queue forward to another after a forward-delay of 1 minute.
    Or can I use transactions to achieve this behaviour.

    Your time is greatly appreciated

    Thanks
    Kiran Rajapur