MDB Instances

Hello. I am newbie in EJB programming, and i have one question I guess
          it must be simple: ¿Can I force Weblogic to mantain just one MDB
          instance? I mean, I want that just one EJB object (instance)would be
          listening for messages (something similar to Singleton pattern). Is
          this possible?
          Thanks for your help
          Rafa

Hi Rafa,
          Set <max-beans-in-free-pool>1</max-beans-in-free-pool> in your
          weblogic-ejb-jar.xml to ensure only one instance is used.
          Jane
          BEA Support
          "Rafa" <[email protected]> wrote in message
          news:[email protected]..
          > Hello. I am newbie in EJB programming, and i have one question I guess
          > it must be simple: ¿Can I force Weblogic to mantain just one MDB
          > instance? I mean, I want that just one EJB object (instance)would be
          > listening for messages (something similar to Singleton pattern). Is
          > this possible?
          > Thanks for your help
          > Rafa

Similar Messages

Limit MDB instance to 1

How can I limit the concurrent number of Message Beans at anytime to one? Will the following settings do the trick?
initial-beans-in-free-pool = 0
max-beans-in-free-pool = 0
TIA

The only way for the container to get an instance is to get an existing instance from the free pool. If all the instances are in use, the container can create additional instances, up to the limit of "max-beans-in-free-pool", and then retrieve one of those instances. If the container can't create any more, because it's at the "m-b-i-f-p" limit, then the thread will wait until one becomes available.
In short, setting "m-b-i-f-p" to 1 means that a maximum of one instance of the bean can exist.

How to limit the number of instances of an MDB?

Hi,
I am using jboss 4.0.5 AS, and we have an mdb which listens to the jboss's jms queue. We are using ejb 3.
we are configuring MDB like this
@MessageDriven(name="LongProcessMessageBean", activationConfig = {
@ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination", propertyValue="queue/examples/OurSampleQueue")
@ActivationConfigProperty(propertyName="maxSession", propertyValue="1")
When there are multiple messages to the queue at the same time, it is creating multiple instances of the MDB, i want to limit the MDB instances to 1 ( I used maxSession=1, but it is not working).
When the messages to the JMS queue are increasing, after certain point it is saying that the unable to allocate memory....threadpool is full.
any suggestion would be appreciated............
thanks.

Hmmmm... I found the cause of the problem. The onMessage() method of the MDB is using some DB backend. This backend was catching an exception and continuing normally, but for some reason, the MDB executed six more times. Something like

Creating new instances of MDBs at runtime

I am creating an application with a single input point (messages on a JMS Queue). The application needs to be multi-threaded, but would like to process the messages sequentially based on the message type.
For example, a message of type A and a message type B can be processed simultaneously, but only 1 message of type A can be processed at a time. So if the application is processing a message of type A, and it receives another type A message, it must complete the first message before processing the second message.
What I would like to do is have a single MDB (called the dispatcher MDB) that listens on the input point (JMS Queue). The dispatcher MDB calls onMessage() which will look at the message type and the forward to another JMS Queue based on the type. For example, if message type is A, send to Queue A, else if message type B, send to Queue B and so on. Each queue would have a MDB instance servicing the messages. In order to process the messages sequentially on each queue, the pool size for each MDB would be 1.
My problem is that I don't know how many message types there are, this is decided at runtime.
How can I create the Queues and register MDB at runtime?
After some research, I have found the ability to create the Queues using JMX. But, I cannot seem to find details on how to create a register an MDB and tell it to listen on a particular Queue. Has anyone had any experience doing such a thing?

OK, i have some code similar to below, where I want to
create a new instance of the class BookRecord which
takes parameters from Book b, which is an instance if
the class Book.
//This is code from the Libraray class
public void addBookRecord(Book b, String author,
String title)
bookHolder = new BookRecord(b, author, title);
}Now this creates a new BookRecord object that has an
author and title which refer to the Book b. Now when i
invoke the method again, choosing the same object for
b as i did last time it creates a second BookRecord
object, when I just want it to overwrite the values of
the previous BookRecord object. how can i do this
simply?
Thanks in advanceWell I am not quite sure if I understood.
But refering to what you wrote I would say:
//This is code from the Libraray class
public void addBookRecord(Book b, String author, String title)
        if(bookHolder.getBook() != b)
           // Not the same book object
           bookHolder = new BookRecord(b, author, title);
         else
            // same book object
            bookHolder.setAuthor(author);
            book.setTitle(tile);
As I said may be totally not what you are looking for.
Regards
Tarik

Several instances of MDB accessing a Q and one rolling back a message

I have one input queue being served by several instances of an identical
          MDB.
          When a problem occurs with an MDB processing one of the messagse read on the
          queue (for instance, it could not forward the answer, the bean is being
          brought down through an exception or otherwise), I would like to rollback
          the message it was processing since it could not complete the job.
          I would like to let the container manage the transaction and use
          setRollbackOnly when the instance of MDB fails or has to abrupty end. What
          would happen to messages that are currently being processed by other MDBs
          (and thus have not been committed) and followed the message that caused the
          rollback in the input queue? In other words, uncomitted messages submitted
          to other MDB instances after the failed MDB started the transaction that
          ultimately failed. Will they also be rollbacked?


          Wim van der Kerkhoven wrote:
          > I have one input queue being served by several instances of an identical
          > MDB.
          >
          > When a problem occurs with an MDB processing one of the messagse read on the
          > queue (for instance, it could not forward the answer, the bean is being
          > brought down through an exception or otherwise), I would like to rollback
          > the message it was processing since it could not complete the job.
          >
          > I would like to let the container manage the transaction and use
          > setRollbackOnly when the instance of MDB fails or has to abrupty end. What
          > would happen to messages that are currently being processed by other MDBs
          > (and thus have not been committed) and followed the message that caused the
          > rollback in the input queue? In other words, uncomitted messages submitted
          > to other MDB instances after the failed MDB started the transaction that
          > ultimately failed. Will they also be rollbacked?
          No. Only the message participating in the rolled back transaction
          will be rolled back. Messages in other transactions will not be
          affected.
          >
          >
          >
          >

How do I specify that I want no more than x instances of my MDB ?

How do I specify that I want no more than x instances of my MDB ?
          After all, I don't want as many MDB instances as messages, what's a queue for then...
          Does Max Beans In Free Pool do the trick ?
          Thank you.
          [att1.html]


Hi Rosalie,
          Max Beans in Free Pool is there for this purpose. Note
          that MDB concurrency is also limited by the thread pool size,
          and that it is often useful to give MDBs their own
          thread pool to prevent them from stealing threads from other
          applications. See:
          http://edocs.bea.com/wls/docs81/ejb/DDreference-ejb-jar.html#dispatch-policy
          You will likely find it useful to read through the
          JMS Performance Guide if you haven't already done so. The above
          information, as well as related info, is included:
          http://dev2dev.bea.com/products/wlserver/whitepapers/WL_JMS_Perform_GD.jsp
          Tom
          Rosalie Mignon wrote:
          > How do I specify that I want no more than x instances of my MDB ?
          >
          > After all, I don't want as many MDB instances as messages, what's a
          > queue for then...
          >
          > Does Max Beans In Free Pool do the trick ?
          >
          > Thank you.
          >
          >
          >
          >
          >
          >
          >
          >
          >

Guaranteed minimum instance for MDB?

Hi all,
Am on WL8.1
Would like to know if I specified the "initial-beans-in-free-pool" parameter to, say 20, would that be sort of minimum instance as well?
And besides application redeploy or server restart, would there be any other circumstances that the number of MDB instance would drop to zero?
Thanks!
regards,
GAB

the number of beans in the free pool could fall down below the initial-beans-in-free-pool limit if the bean instances are destroyed and no new mdbs are created. mdb instances will be destroyed (ie, not returned back to the pool) if there is non-application exception thrown in the onMessage method.
there are various monitoring stats as well as ratios that we provide. Please check:
http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_ejbcomponent_monitor_monitor_ejbmdb.html
and
http://e-docs.beasys.com/wls/docs81/perform/EJBTuning.html#1139147
cheers,
Mihir

Why do I see only one MDB?

Hi,
I'm having a weird issue running my MDB on SAS9.01: I have a stateless EJB JMS producer and an MDB which is both a consumer and a producer.
The test logic is this:
1. the ejb sends a single message
2. the mdb's onMessage method is triggered and does the following:
if the methos has not been called over 5 times (to prevent infinite loops, you'll see why in a sec):
a. sends another message to the queue
b. sleeps for 5 secs
I would have expected that mdb instances would deal with the messages simultaneously, but this is not the case. The messages are handled in a SERIALIZED manner by 2 MDB instances (confirmed by printing out the mdb's toString() result).
why? how can I make sure that messages are consumed more aggressively?
thanks.

problem solved: needed to wrap the message-sending operation in its own transaction, so it completes before the mdb sleeps. This probably means I'll have to work harder to manage the state of my entity beans, but I don't see any other way..

Message Driven Bean -- Instance Creation..

As we know MDB (inJMS) acts as a listener to a message coming from either a topic/queue. The instance of MDB is created by the EJB Container and the no. of instances created depend upon the corresponding values specified in the Deployment-Descriptor. So we never have to create instance of MDB bcoz container takes care of itself. MDB is eventDriven and the method onMessage is fired when topic/queue receives a message.
Now, can I have a scenario where my client creates an instance of MDB explicitly. Say I have an MDB by name TestMDB, I create an instance of MDB using new keyword something like the below code:
TestMDB testMDB = new TestMDB();
The client grabs messages which are recd. using onMessage of TestMDB. I put the msgs recd. in onMessage method into some kind of HashMap and return it to the client. This for sure satisfies my requirement, but EJB specification says MDB instances are created by the EJB Container itslef and that does not give me an easy feeling.
Are there any caveats of creating instances of Message Driven Bean ??

Hi,
Why would you like to create your own MDB instance?
Is it because you don�t want to use an EJB container?
Otherwise, you should know that the container is doing a lot of work under the cover. It is not that simple to achieved concurrent message processing.
I would really recommend you to either use an EJB container or to redesign your application. If you really don�t want to use a heavy weight EJB container you can have a look at Arjuna�MDS that provides you with a light weight container allowing to deploy MDBs like applications.
Hope this helps,
Arnaud
www.arjuna.com

MDB vs standalone JMS client

I have implemented a transformation server as a JMS client. This is not
written as a EJB bean, partly because I'm not very familiar with EJB beans.
I'm being told MDB is the way to go (I'm a bit reluctant in front of the
additional work) for the usual reasons : transaction-control (not really an
issue right now for me but may become one), ease of deployment and
centralized monitoring. Fair enough.
My standalone JMS client creates a lot of variables at initialization (such
as a precompiled XSLT stylesheet to substantially improve the speed of each
transformation).
Where should this be created if I were to convert my standalone JMS client
into an MDB ? In ejbCreate() ?
I'm also a bit worried about a few aspects :
1) Performance, the size of requests may vary tremendously and I currently
use a synchronous receive on my input queue, is this more efficient (I pull
messages when I'm ready) than using beans and onMessage() ? In other words,
will the container try to push message notifications to MDB bean instances
that are not ready ?
2) My standalone JMS consumer is also a producer to several destinations
(including temporary queues, permanent queues and topics), is there any
limitation to the use of JMS destinations in an MDB (what about selectors ?)
vs a standalone java JMS application?
3) My standalone JMS consumer creates a few threads per request. Any gotchas
in a MDB vs a standalone Java JMS application ? Are MDB passivated at any
time ?
Many thanks for any answer,
Rosalie
Rosalie

Rosalie Mignon wrote:
I have implemented a transformation server as a JMS client. This is not
written as a EJB bean, partly because I'm not very familiar with EJB beans.
I'm being told MDB is the way to go (I'm a bit reluctant in front of the
additional work) for the usual reasons : transaction-control (not really an
issue right now for me but may become one), ease of deployment and
centralized monitoring. Fair enough.There's a number of MDB advantages over writing your own JMS consumers.
I would recommend MDBs for JMS consumers running within WLS. If you
have a JMS consumer that is a separate (say client) process, then
vanilla JMS is still the way to go.
The MDB container takes care of things like reconnecting you to JMS if
it fails. It supports foreign JMS providers so your MDBs will work with
"foreign" messaging systems like MQ-Series.
>
My standalone JMS client creates a lot of variables at initialization (such
as a precompiled XSLT stylesheet to substantially improve the speed of each
transformation).
Where should this be created if I were to convert my standalone JMS client
into an MDB ? In ejbCreate() ?Yes, ejbCreate would be fine.
>
I'm also a bit worried about a few aspects :
1) Performance, the size of requests may vary tremendously and I currently
use a synchronous receive on my input queue, is this more efficient (I pull
messages when I'm ready) than using beans and onMessage() ? In other words,
will the container try to push message notifications to MDB bean instances
that are not ready ?I'm not sure I understand. You will have a pool of MDB instances all
receiving from the queue. When an instance is available and there is a
message pending, the EJB/JMS containers will call your MDB's onMessage
implementation.
>
2) My standalone JMS consumer is also a producer to several destinations
(including temporary queues, permanent queues and topics), is there any
limitation to the use of JMS destinations in an MDB (what about selectors ?)
vs a standalone java JMS application?Not that I can think of.
>
3) My standalone JMS consumer creates a few threads per request. Any gotchas
in a MDB vs a standalone Java JMS application ? You are not really allowed to create threads from an EJB. Why do you
need to create threads? In general, we wouldn't recommend that
server-side applications create new threads on each request.
Are MDB passivated at any
time ?
No
Many thanks for any answer,Your domain name is an unusual one for the J2EE world. If you can tell
us, I'd be interested to know what you're doing.
-- Rob
>
Rosalie
Rosalie

Concurrent MDBs

Hi!
          SUN JMS specs say, that "The session used to create the message consumer
          serializes the execution of all message listeners registered with the
          session. At any time, only one of the session's message listeners is
          running." As I understand this statement, I can be sure, that for particular
          session only one listener is active in any moment of time.
          Further statement says that "In the J2EE 1.3 platform, a message-driven bean
          is a special kind of message listener." And, "Like a stateless session
          bean, a message-driven bean can have many interchangeable instances running
          at the same time. The container can pool these instances to allow streams of
          messages to be processed concurrently. Concurrency can affect the order in
          which messages are delivered, so you should write your application to handle
          messages that arrive out of sequence. "
          So, in J2EE real JMS listener is located somewhere in the app server and
          gets messages in serialized manner, but it passes these messages to MDBs,
          which can run concurrently?
          The questions are:
          * does serialized mode of standard JMS listeners ensure the correct message
          order?
          * how I can serialize message processing, using MDBs? I use WLS7, if it may
          help. I guess I can tune server to use only one instance of MDB... Any other
          approaches?


There have been several posts on this topic in the past. If I remember
          correctly, while you will be able to maintain order integrity with a single
          consumer or MDB instance, it would work only as long as there are no
          rollbacks. There is no guarantee of ordering in the event of rollbacks.
          Thanks,
          Adarsh
          "Michael Jouravlev" <[email protected]> wrote in message
          news:[email protected]...
          > Hi!
          >
          > SUN JMS specs say, that "The session used to create the message consumer
          > serializes the execution of all message listeners registered with the
          > session. At any time, only one of the session's message listeners is
          > running." As I understand this statement, I can be sure, that for
          particular
          > session only one listener is active in any moment of time.
          >
          > Further statement says that "In the J2EE 1.3 platform, a message-driven
          bean
          > is a special kind of message listener." And, "Like a stateless session
          > bean, a message-driven bean can have many interchangeable instances
          running
          > at the same time. The container can pool these instances to allow streams
          of
          > messages to be processed concurrently. Concurrency can affect the order in
          > which messages are delivered, so you should write your application to
          handle
          > messages that arrive out of sequence. "
          >
          > So, in J2EE real JMS listener is located somewhere in the app server and
          > gets messages in serialized manner, but it passes these messages to MDBs,
          > which can run concurrently?
          >
          > The questions are:
          > * does serialized mode of standard JMS listeners ensure the correct
          message
          > order?
          > * how I can serialize message processing, using MDBs? I use WLS7, if it
          may
          > help. I guess I can tune server to use only one instance of MDB... Any
          other
          > approaches?
          >
          >
          >
          >

Message sitting in Queues for 30 minutes before MDB picks them up

We're seeing a situation where we place messages on a queue and a small percentage of them will sit on the queue for 30 minutes before being picked up by the MDB to process. Anyone see this before?
          Here is the background. We're running 3 distributed queues on a cluster of 4 Weblogic 8.1 sp3 servers. The 30 minute issue happens on all 3 queues on all 4 servers. Currently we do not see a pattern. It can happen at a busy hour and in the middle of the night with nothing going on. During a busy timeframe, we can get up to 50 msg that hangup over a few minutes; less than 5 minutes.
          Our Service is an enterprise email service where various clients send email request to us via EJB. The EJB puts an entry into the database and puts a request msg into the queue. The MDB pulls it off the queue sends it to an email subsystem and updates the database.
          We added log msgs in both the EJB and MDB to track messages and narrowed it down to the requests just sitting in the JMS queue. We DO NOT set a delivery time via setJMSDeliveryTime().
          As mentioned is happens anytime during the day (busy or idle), may go for days without occuring, on any of the 3 JMS queues, on any of the 4 cluster servers, and for any of the clients. It's consistantly 30 minutes. This occurs on a small number of requests, but is enough to concern our business owner.
          Any thoughts on possible problems or any thoughts on monitoring or tracking down the issue is greatly appreciated.
          Thanks. Later...
          - Wayne

One possibility is that the messages have already been pushed to an MDB instance in the JMS asynchronous consumer pipeline, but the MDB instance has stalled during message processing - which delays processing of the following messages. The waiting messages count as "pending" in the JMS statistics.
          You can reduce the number of messages in a JMS asynchronous consumer's pipeline via the "MessagesMaximum" connection factory setting (default is 10). First: create a custom connection factory with transactions enabled (to support transactional MDBs), and ack-mode set to "previous" (to support pub/sub MDBs), and MessagesMaximum set to its lowest possible value. Second: specify this connection factory's JNDI name in the MDB's weblogic descriptor.
          Tom, BEA

MDB topic listener and concurrent processing

Hello to everybody.
I ve prototyped simple db publisher ,which publishes changed data from database to JMS topic. Then I have my MDB which listens on JMS topic.
I setup and implemented all correctly and it worked. There was 1 consumer = 1 mdb instance. Then I tried to do load testing , So I triggered 8000 changes from database. The db adapter did the job and published the 8000 messages on the JMS topic in a while. To mimic processing in MDB I put the sleep(10seconds) in MDB.
MDB topic processing seems to me as not concurrent one. Why? I observed 10 message decrease with 5-10 seconds.
What I expected was: concurrent processing of 8000 JMS messages by 1 MDB (so MDB is poolable component isnt it?).
So for 500 instances of topic MDB and 8000 messages on the JMS topic, I expected at least 8000/500 X 10 = 160 seconds to process message load.
I am using WLS 816.
Can You give me some hits.
Thanks
Roman

I did the same test on Weblogic 10 and it worked as expected. MDB durable subscriber consumed 8000 messages (each msg processing had 10 secs sleep inside.) within 2 minutes. So it is ok.
But why it did not worked on WLS 8.1? Is this a bug ?

OEMS/10.1.3.2 MDB/AQ via Resource Adapter - message gone but no "onMessage"

Hi I have a very simple ear file containing an EJB/MDB and a JMS Resource Adapter configured to listen to an AQ, JMS Provider. What I see happening is that messages are gone from the AQ (after some time), I also see some ejb activitiy - enabled via logging - but my onMessage is never called. Was could be causing this?

Things are getting stranger by the minute (for me)
I've just changed my PL/SQL procedure to include at least one of the JMS properties which seem necessary for MDB's to pick things up: JMS_OracleDeliveryMode. With that change, and making sure the rest of the header properties (like username) were in order, I saw my MDB picking up messages that were enqueue via PL/SQL... but.... only if a MDB instance was readily available.
Whenever ejbRemove() was called by the container, entering another JMS message in the queue using PL/SQL didn't result in the onMessage() being called. Message where still available in 'READY' state. Now what is really disturbing is that whenever I called my standalone Java client to enter a new JMS message, obviously this was picked up - but as a side effect every subsequent enqueue using PL/SQL also resulted in onMessage() being called.

2 MDBs inserting same row in table

Hi all,
I have a unique requirement.
Environment:
Application is in cluster. I have kept 1 MDB instance on each server. Each MDB listening to same external JMS queue.
A database table row is inserted and one existing is updated by MDBs whenever they receive messages.
Situation:
JMS queue has 2 messages which have same ID value which exists in database.
1st MDB queries table to get existing record from database.
As MDBs are in cluster, 2nd MDB also does same action simultaneously.
As both find old record in database, they insert their data in table.
Thus, each MDB will insert a row in table.
Actually, latest message in queue should get inserted first.
I don't want to lock any database rows.
Is there any design option?
Please let me know suggestions and solutions.
Thanks,
Plad

"prasanna laddha" <[email protected]> wrote in message news:23908280.1098964315854.JavaMail.root@jserv5...
Environment:
Application is in cluster. I have kept 1 MDB instance on each server. Each MDB listening to same external JMS queue.
A database table row is inserted and one existing is updated by MDBs whenever they receive messages.
Situation:
JMS queue has 2 messages which have same ID value which exists in database.
1st MDB queries table to get existing record from database.
As MDBs are in cluster, 2nd MDB also does same action simultaneously.
As both find old record in database, they insert their data in table.
Thus, each MDB will insert a row in table.
Actually, latest message in queue should get inserted first.
I don't want to lock any database rows.
Is there any design option?Dedicate only one cluster node that handles external JMS requests.
Regards,
Slava Imeshev

MDB Instances

Similar Messages

Maybe you are looking for