MDB instansiation...

[lolsson]

I have a question about how jboss 2.4.1 (RH Linux 6.2)
handles MDB instances.

I have a simple test application that consists of one
MDB that consumes messages from a queue. The MDB prints
a log message to System.err in its ejbCreate() method,
its ejbDestroy() method, and in the onMessage() method.
The log-message contains the hashCode() of the MDB instance.

A simple test client loops a 100 times and:
1) Writes a tiny dummy message to the queue
2) Sleeps two seconds.

When I run the test client I can see how the MDB
ejbCreate() method is called 100 times and the
onMessage is called 100 times. The ejbDestroy
method is never called. The hascode that appears
in the log messages seems to be different for each
invocation of onMessage().

I know that it is not my business as a MDB writer
to try to control how the container creates MDB
instances and pass messages to them - but why
does the container not create just one MDB instance
and pass all messages to that instance? It is not as
if the queue is being overwhelmed with data - the
tiny test messages arrive with two second intervals.

In a separate test the two second wait in the
loop in the test client was removed. This resulted
in:
A) 115 calls to ejbCreate()
B) 100 calls to onMessage()
C) Zero calls to ejbDestroy

Lars

[pra]

It would be interesting to see the results if you increase the number of times you send a message. 100 happends to equals the default instance pool size, so what you might see is the instance pool filling up.

//Peter

[lolsson]

I let the client send 1000 messages with a two second
delay between each messsage, This led to:

1) 1001 calls to ejbCreate()
2) 1000 calls to onMessage()
3) Zero calls to ejbRemove()

In a similar experiment the client sent 2460 messages
with a one second delay between messages.
This led to:

1) 2461 calls to ejbCreate()
2) 2460 calls to onMessage()
3) Zero calls to ejbRemove()

Lars

[pra]

Hi,
I have checked it somewhat more and I am now inclined to consider this a bug. It was introduced between 2.4.0 and 2..4.1 by some changes to the instance pool code where instances should actually never be pooled.

There seems to not be total agreement if this is a bug or not on the dev mailinglist, so we will see how this will end.

//Peter

[pra]

It should be fixed now in the 2.4.1 cvs tree.

//Peter