JBOSS EJB Container Bug ?!

[jeffandrews]

I have been trying to post my problem, looking for an answer for some time now on defferent forums now, with no answer yet... Please help provide any feedback if you can. As I'm not sure if my current problem is due to a JBOSS container bug, or configuration requirements that I have missed some where.

------ My previously posted message -----

Due to a previouse recommendation on one of these
Forums,I have upgraded from JBoss_2.4.0-Tomcat_3.2.3
to JBoss_2.4.3-Jetty_3.1.3-1. I'm running my JBoss
on Linux.

My problem/question is; How can I force the container
pool
configuration size of JBoss for a deployed stateless
session bean (for example)to not exceed a specified
MaximumSize, based on what I have defined it to be
in the jboss.xml file used for deployment??

I tried many defferent kind of MaximumSizes, but it
seems to me (from actual performance tests), that no
matter what I specify as a MaximumSize for my deployed
stateless session bean, JBoss will always allocate
a bean instance for each request, even if the number
of concurrent (client) requests to that bean (pool)
exceeded the MaximumSize specified for the bean's
container pool configuration (specified within
jboss.xml at deployment time)....The same kind of behaviour problem was also found with deployed stateful session beans type as well as deployed entity beans type!!!

For example:
If I set the container pool configuration (of my bean)
MinimumSize = 1, and MaximumSize = 1 (Meaning that
there should ONLY be one bean instance in the pool to
be shared among requesting clients).....And then I had
8 concurrent (clients) requests (at the same time).
All 8 of those requests were able to get a remote
reference to a bean instance (and uses it) at the same
time. As apposed to all 8 sharing the single bean
instance that should have ONLY bean in the pool...

What am I messing ?!! Please help.... As I have bean
struggling with this kind of a problem for over a month
now.

Jeff

[adrian.brock]

Hi,

To answer your question directly. What you are doing
is correct. By setting the maximum pool size to 8
there is only ever a maximum of 8 beans in the pool.

This is not what you want though. Because if all 8 are
in use, the container will create a further bean to
process a new request. The point is, it won't put the
new one back in the pool. It will just discard it.

What you actually want to control is the number of
connections, not the pool size.

I'm not sure of the detailed implementation, but it
might be possible to do this by using a custom
ServerSocketFactory.

See http://www.jboss.org/online-manual/HTML/ch13s131.html

It should be possible to monitor the number of active
connections by sub-classing ServerSocket.

When your server socket is asked to accept()
you look down previously accepted sockets to see if
they are closed.
Provided there are less than eight
unclosed you accept() on the real server socket.
Otherwise let the backlog build up until there are
less than 8 sockets unclosed.

I've never done anything like this myself, this is just an idea. There may be an easier way to control
the number of active connections :-)

Regards,
Adrian

[jeffandrews]

Thanks Adrian;

"What you actually want to control is the number of
connections, not the pool size."

Why not control the pool size instead?
Otherwise, the purpose of the pool would just be to
make available a number of instances (pre-
instantiated) of a bean, in order to save (JUST) the
cost of it's instantiation when needed. As opposed to
allowing a control on the maximum number of bean instances that can be allowed to exist (running) within a pool.

THough what you have suggested could work, I would believe that it would make greater since to allow for
the option of control where you could always
explicitly spicify a cap for the maximum number of
concurrent clients that could run concurrently trying
to access JBoss's bean resources. This is ofcourse to
insure performance qualities of a deployed JBoss J2EE
application, on a specific machine (where it has
limited resources always). Otherwise, it would be easy
then (under concurrent client's requests stress), to run over the limited resources that are available within a server that hosts JBoss and it's deployed
J2EE application. The thing that would easily lead to
performance degradation, and possibly crashing the
server.

Jeff

[adrian.brock]

Hi,

Having delved a bit deeper, there is an
org.jboss.ejb.plugins.SingletonStatelessInstancePool
that nearly does what you want.
It only allows one client to access the bean at any
given time when it is "synchronized".

This could be used as a basis for a custom instance
pool to do what you want.
Except there would be an array of Enterprise Contexts
and in use flags rather than just one of each.

The importXml would load the maximum number of clients.

I wouldn't change the default instance pool.

Regards,
Adrian

[adrian.brock]

Hi Jeff,

I see from 2.4.4 a new boolean policy flag has been
added "strictmaximumsize".
This means the maximumsize controls the active as well
as the inactive pooled beans.

Regards,
Adrian