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.

Similar Messages

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

Java.lang.OutOfMemoryError -- Is there a way to limit BPEL instances number

Hi All,
My BPEL process is using JMS adapter to read the JMS queue. Whenever a new message arrives, a new BPEL instance is created. However, when the message gets bigger and multiple messages arrive at queue at the same time, the OC4J gets java OutOfMemory (heap space) error and was forced shutdown. I'm wondering if there's any way to limit the BPEL instance created, say, only one at a time, and the messages would be processed in sequence. Would this be a good way to not use so much heap at one time? Is there a way to limit the BPEL instance created?
Thanks for your help!
Michelle

Take a look at how to configure Jms polling interval (talks about a property that you can set to introduce a delay in between dequeues). That might be of some help to start with.
It is supposed to work exactly the way you want it i.e the activation agent does a dequeue and hand off to bpel engine (which creates an instance and uses the same thread to run as much of that instance as possible i.e till the first dehydration point). So, if your process has a dehydration point right at the beginning (which could be due to invocation of another async process, or wait or ...), you could very well see this thread go right back and process the next available message.
I believe this is a generic problem that is not necessarily jms adapter specific. One way would be to split up your process into three processes:
1. "Kickoff" process which contains just a "receive" associated with the activation agent followed by an invocation of a "Controller" process
2. "Controller" process which checks for the provided input as to which process it needs to invoke, and then goes on to check how many instances of that process are currently running; if this number is below a certain threshold, kick off the main process providing it the necessary payload gotten from the "KickOff" process
3. "Main" process which is same as your current process except that it is a typical async process without the adapter "receive" partner link
So, the idea being that for any process where you want to introduce a control-flow mechanism, you would split it into #1 and #3 above. Have one generic Controller process, which caters to all of the processes.
Would be interested in learning if others have solved this in a generic way.

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

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

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

Object Level and Folder Level Instances Limit on R3?

Hi there,
We've been thinking about setting a global limit on instances of 35, but were wondering if we can apply a limit of 50 only on certain reports?
This is only for reports where the business has justified that they will need to go over that.
Basically, will object level limits override folder level or even global level limits?
Many thanks,
Nawar

It will override Global level limits.
Create a User and apply limits to that particular User , so that where ever that user ran a report that limits the instances according to user limit.
Thanks,
Anil

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.
          >
          >
          >
          >
          >
          >
          >
          >
          >

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 ?

Limit MDB instance to 1

Similar Messages

Maybe you are looking for