Re: [JBoss-dev] JBOSS EJB Container Bug ?!
Hi Scott; I will be trying out JBoss_2.4.4-Jetty_3.1.3-1_beta tonight. I must say that you and your [JBoss-dev] team (Especially Sacha Labourey, and Vincent Harcq) are very responsive, and helpful. If anything, I'm more sure today than yesterday that I'm investing my time, as well as our software's platform into the right (BEST) direction. Wishing you all much success, and Happy new year ;) Thanks Jeff. PS: Can't promise that this will be the last you hear from me ;) From: Scott M Stark [EMAIL PROTECTED] Reply-To: Scott M Stark [EMAIL PROTECTED] To: jeff andrews [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Date: Sat, 29 Dec 2001 12:10:06 -0800 Hi Scott; Thanks for your assistance. I'm wondring about two things: - When can I expect this feature inhavcement, and which version of JBoss should I look for it in? Now in 2.4.4, see https://sourceforge.net/tracker/index.php?func=detailaid=497673group_id=22 866atid=381174 - Also when testing the performance behaviour of stateful session beans type on JBoss, the performance was always the same with no defference, wither we had a cache min/max-capacity of 1, 10, 20, ..etc for 5 (for example) concurrent requesting clients. Shoudn't the performance behviuor improve as I increase the initial cache min/max-capacity value , in order to aviode the performance cost of client's request cache misses. Or is the same kind of behaviour is happenning as what is/was happenning with the bean pooling (above), for the case of concurrent requesting clients ? Would the same thing apply to Entity bean types to some degree too? Its probably the same lax implementation of the max bound, but this is a different pooling layer that I have not looked at for a while. Entity beans are not effectively pooled due to changes to generalize the locking policy, and are still not in 2.4.4. PS: For some reason I'm only able to get e-mails from [JBoss-dev] for those ones that explicitly include me in their To: address list. General [JBoss-dev] communications I'm not able to receive/see. That's why I missed your e-mail earlier. You don't have this email address subscribed to jboss-dev so there is no reason you should be getting posts. Check your subscription address or create one. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
The beta does not have the change. It exists only in the final release of 2.4.4. - Original Message - From: jeff andrews [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 6:28 PM Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Hi Scott; I will be trying out JBoss_2.4.4-Jetty_3.1.3-1_beta tonight. I must say that you and your [JBoss-dev] team (Especially Sacha Labourey, and Vincent Harcq) are very responsive, and helpful. If anything, I'm more sure today than yesterday that I'm investing my time, as well as our software's platform into the right (BEST) direction. Wishing you all much success, and Happy new year ;) Thanks Jeff. PS: Can't promise that this will be the last you hear from me ;) From: Scott M Stark [EMAIL PROTECTED] Reply-To: Scott M Stark [EMAIL PROTECTED] To: jeff andrews [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! Date: Sat, 29 Dec 2001 12:10:06 -0800 Hi Scott; Thanks for your assistance. I'm wondring about two things: - When can I expect this feature inhavcement, and which version of JBoss should I look for it in? Now in 2.4.4, see https://sourceforge.net/tracker/index.php?func=detailaid=497673group_id=2 2 866atid=381174 - Also when testing the performance behaviour of stateful session beans type on JBoss, the performance was always the same with no defference, wither we had a cache min/max-capacity of 1, 10, 20, ..etc for 5 (for example) concurrent requesting clients. Shoudn't the performance behviuor improve as I increase the initial cache min/max-capacity value , in order to aviode the performance cost of client's request cache misses. Or is the same kind of behaviour is happenning as what is/was happenning with the bean pooling (above), for the case of concurrent requesting clients ? Would the same thing apply to Entity bean types to some degree too? Its probably the same lax implementation of the max bound, but this is a different pooling layer that I have not looked at for a while. Entity beans are not effectively pooled due to changes to generalize the locking policy, and are still not in 2.4.4. PS: For some reason I'm only able to get e-mails from [JBoss-dev] for those ones that explicitly include me in their To: address list. General [JBoss-dev] communications I'm not able to receive/see. That's why I missed your e-mail earlier. You don't have this email address subscribed to jboss-dev so there is no reason you should be getting posts. Check your subscription address or create one. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Who is Scott ? And where do I find his answer?
Actually I'm looking forward to hear from you (or others that could
help) about:
Wither there a way to turn this current (extended) concurrent JBoss
handling off, and rather allow additional requests (to the available
instances within a pool) to wait until (freed) bean instances are
returned back to the pool..?
Or is the only way for me to currently address it if via modifying the
org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have
outlined below. If so, is there other methods that I should also be
modifying, in order to insure that all bean's container types are
behaving the same?
Jeff.
PS: Do you think that I should post this in the to-do list for future
JBoss releases (if it exists)?
From: Sacha Labourey [EMAIL PROTECTED]
To: jeff andrews [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Date: Fri, 28 Dec 2001 10:38:45 +0100
So I guess you have your (good) answer from Scott ;)
-Message d'origine-
De : jeff andrews [mailto:[EMAIL PROTECTED]]
Envoyé : jeudi, 27 décembre 2001 20:41
À : [EMAIL PROTECTED];
[EMAIL PROTECTED]
Objet : RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Hi Sacha;
Thanks allot for the insightful reply. It was the answer that I
long waited
for.
Given what you stated/explained:
JBoss has a goal: to serve each request immediately.
Consequently, if the
pool is empty, a new instance is created and, once the instance
is returned
to the pool, the instance will be freed (and not returned back to
the pool).
Thus, JBoss don't wait for an instance to become available to serve
concurrent requests.
J2EE Applications that are deployed on JBoss will not be able to
guarantee a
specific performance at all times. In other-words; if I'm selling a J2EE
application product/solution that is deployed on JBoss within a client's
server machine, and the client requires that there would always be a
guaranteed performance (i.e. throughput) for each requesting/connecting
client to a particular ejb (bean) resource. JBoss goal stated
above, would
take away the chance of me offering a solution/product application that
would optimally run, and meet the required performance on a particular
machine (available) resources, that could be stated as part of the
product's/solution's installation minimum requirements.
With this king of JBoss flexibility that you have stated, it's
true that you
would accommodate all requesting (concurrent) clients, but this
would be on
the expense of the overall performance that one would like to insure as
a
minimum.
I realize that even in the J2EE spec. for v1.2 or v1.3 (Section 5.4.3)
it
was not clearly required/specified how container (available
instance bean)
pool resources should be managed/handled. However, since many of
the other
J2EE vendor products that I have tried (i.e. WLS, iPlanet,
Borland) operates
on this kind of performance configurational guarantee, where concurrent
clients will have to wait until available bean instance resources
(that have
been configured with) are available, in order to reuse them
(where it can't
share).
And since I'm really more interested in the use of JBoss for promoting
deployment of our application's solutions on it for our clients (for
obviouse reasons, especially cost and ease of use), is there a
way to turn
this current (extended) concurrent JBoss handling off, and rather allow
additional requests (to the available instances within a pool) to
wait until
(freed) bean instances are returned back to the pool..?
Or is the only way for me to currently address it if via modifying the
org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have
outlined below. If so, is there other methods that I should also be
modifying, in order to insure that all bean's container types are
behaving
the same?
Appreciate very much your thoughts and feedbacks. Thanks allot in
advance.
Regards;
Jeff.
From: Sacha Labourey [EMAIL PROTECTED]
To: jeff andrews [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Date: Thu, 27 Dec 2001 17:56:03 +0100
Hello Jeff,
For you problem, take a look at
org.jboss.ejb.plugins.AbstractInstancePool.get():
public synchronized EnterpriseContext get()
throws Exception
{
//DEBUG Logger.debug(Get instance +this);
if (!pool.empty())
{
mReadyBean.remove();
return (EnterpriseContext)pool.pop();
} else
{
try
{
return create(container.createBeanClassInstance());
} catch (InstantiationException e)
{
throw new ServerException(Could not instantiate
bean,
e);
} catch (IllegalAccessException e
[JBoss-dev] JBOSS EJB Container Bug ?!
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 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Hello Jeff,
For you problem, take a look at
org.jboss.ejb.plugins.AbstractInstancePool.get():
public synchronized EnterpriseContext get()
throws Exception
{
//DEBUG Logger.debug(Get instance +this);
if (!pool.empty())
{
mReadyBean.remove();
return (EnterpriseContext)pool.pop();
} else
{
try
{
return create(container.createBeanClassInstance());
} catch (InstantiationException e)
{
throw new ServerException(Could not instantiate bean, e);
} catch (IllegalAccessException e)
{
throw new ServerException(Could not instantiate bean, e);
}
}
}
As you can see, with this implementation, JBoss has a goal: to serve each
request immediately. Consequently, if the pool is empty, a new instance is
created and, once the instance is returned to the pool, the instance will be
freed (and not returned back to the pool). Thus, JBoss don't wait for an
instance to become available to serve concurrent requests.
= the pool size will never exceed the size you indicate in your deployment
descriptor *but* the number of active instances *may* be bigger if
concurrent acccess require it.
What am I messing ?!! Please help As I have bean
struggling with this kind of a problem for over a month
now.
And in 10 seconds of JBoss consulting you have your answer ;)
Cheers,
Sacha
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Hi, On 2.4 the pool is never pre-feed with new instances, instead the pool is feed after the use of an instance. And depending on the x in 2.4.x, the pool may have a size of 1 all the time (no reuse at all). There were good reasons for that linked to locking, read archives if you want more infos. Check this : https://sourceforge.net/tracker/?func=detailaid=496326group_id=22866a tid=381174 It will work on Jboss 2.4.4 latest cvs but the dtd/xml files were not changed, you need to change standardjboss.xml like this : container-pool-conf feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-pol icy feeder-policy-conf capacity100/capacity increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. 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 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
So why was the MaxSize dropped and a feeder pool capacity config element added? The instance pool now grows to the maximum concurrent use count and capacity is a redundant item that should simply be the pool MaxSize value. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'jeff andrews' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 9:06 AM Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! Hi, On 2.4 the pool is never pre-feed with new instances, instead the pool is feed after the use of an instance. And depending on the x in 2.4.x, the pool may have a size of 1 all the time (no reuse at all). There were good reasons for that linked to locking, read archives if you want more infos. Check this : https://sourceforge.net/tracker/?func=detailaid=496326group_id=22866a tid=381174 It will work on Jboss 2.4.4 latest cvs but the dtd/xml files were not changed, you need to change standardjboss.xml like this : container-pool-conf feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-pol icy feeder-policy-conf capacity100/capacity increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. 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 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Without a feeder-policy, the MaxSize have no meaning : the pool never grows. In other words, having to define the size of something that don't grow seemed confusing to me. So I thought it was better to make it a part of feeder-policy-conf. Then I choose to change the name from MaxSize to capacity to avoid confusion with previous definition/place inside the xml. If you consider this is more confusing, I can change it to: container-pool-conf MaximumSize100/MaximumSize feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-pol icy feeder-policy-conf increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: jeudi 27 décembre 2001 19:14 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! So why was the MaxSize dropped and a feeder pool capacity config element added? The instance pool now grows to the maximum concurrent use count and capacity is a redundant item that should simply be the pool MaxSize value. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'jeff andrews' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 9:06 AM Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! Hi, On 2.4 the pool is never pre-feed with new instances, instead the pool is feed after the use of an instance. And depending on the x in 2.4.x, the pool may have a size of 1 all the time (no reuse at all). There were good reasons for that linked to locking, read archives if you want more infos. Check this : https://sourceforge.net/tracker/?func=detailaid=496326group_id=22866 a tid=381174 It will work on Jboss 2.4.4 latest cvs but the dtd/xml files were not changed, you need to change standardjboss.xml like this : container-pool-conf feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-p ol icy feeder-policy-conf capacity100/capacity increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. 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 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free
RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Hi Sacha;
Thanks allot for the insightful reply. It was the answer that I long waited
for.
Given what you stated/explained:
JBoss has a goal: to serve each request immediately. Consequently, if the
pool is empty, a new instance is created and, once the instance is returned
to the pool, the instance will be freed (and not returned back to the pool).
Thus, JBoss don't wait for an instance to become available to serve
concurrent requests.
J2EE Applications that are deployed on JBoss will not be able to guarantee a
specific performance at all times. In other-words; if I'm selling a J2EE
application product/solution that is deployed on JBoss within a client's
server machine, and the client requires that there would always be a
guaranteed performance (i.e. throughput) for each requesting/connecting
client to a particular ejb (bean) resource. JBoss goal stated above, would
take away the chance of me offering a solution/product application that
would optimally run, and meet the required performance on a particular
machine (available) resources, that could be stated as part of the
product's/solution's installation minimum requirements.
With this king of JBoss flexibility that you have stated, it's true that you
would accommodate all requesting (concurrent) clients, but this would be on
the expense of the overall performance that one would like to insure as a
minimum.
I realize that even in the J2EE spec. for v1.2 or v1.3 (Section 5.4.3) it
was not clearly required/specified how container (available instance bean)
pool resources should be managed/handled. However, since many of the other
J2EE vendor products that I have tried (i.e. WLS, iPlanet, Borland) operates
on this kind of performance configurational guarantee, where concurrent
clients will have to wait until available bean instance resources (that have
been configured with) are available, in order to reuse them (where it can't
share).
And since I'm really more interested in the use of JBoss for promoting
deployment of our application's solutions on it for our clients (for
obviouse reasons, especially cost and ease of use), is there a way to turn
this current (extended) concurrent JBoss handling off, and rather allow
additional requests (to the available instances within a pool) to wait until
(freed) bean instances are returned back to the pool..?
Or is the only way for me to currently address it if via modifying the
org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have
outlined below. If so, is there other methods that I should also be
modifying, in order to insure that all bean's container types are behaving
the same?
Appreciate very much your thoughts and feedbacks. Thanks allot in advance.
Regards;
Jeff.
From: Sacha Labourey [EMAIL PROTECTED]
To: jeff andrews [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?!
Date: Thu, 27 Dec 2001 17:56:03 +0100
Hello Jeff,
For you problem, take a look at
org.jboss.ejb.plugins.AbstractInstancePool.get():
public synchronized EnterpriseContext get()
throws Exception
{
//DEBUG Logger.debug(Get instance +this);
if (!pool.empty())
{
mReadyBean.remove();
return (EnterpriseContext)pool.pop();
} else
{
try
{
return create(container.createBeanClassInstance());
} catch (InstantiationException e)
{
throw new ServerException(Could not instantiate bean,
e);
} catch (IllegalAccessException e)
{
throw new ServerException(Could not instantiate bean,
e);
}
}
}
As you can see, with this implementation, JBoss has a goal: to serve each
request immediately. Consequently, if the pool is empty, a new instance is
created and, once the instance is returned to the pool, the instance will
be
freed (and not returned back to the pool). Thus, JBoss don't wait for an
instance to become available to serve concurrent requests.
= the pool size will never exceed the size you indicate in your
deployment
descriptor *but* the number of active instances *may* be bigger if
concurrent acccess require it.
What am I messing ?!! Please help As I have bean
struggling with this kind of a problem for over a month
now.
And in 10 seconds of JBoss consulting you have your answer ;)
Cheers,
Sacha
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
That is not true. The pool grows to MaxSize as instances are created and then freed. The free method pushes contexts onto the pool stack if reclaim is true. On the 2.4 branch I have dropped the capacity config element and added a getMaxSize() method to InstancePool and this is used by the TimedInstancePoolFeeder class to determine the max pool capacity. You should do the same on main. Don't drop configuration elements without discussing the change, especially on the 2.4 branch. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 11:07 AM Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! Without a feeder-policy, the MaxSize have no meaning : the pool never grows. In other words, having to define the size of something that don't grow seemed confusing to me. So I thought it was better to make it a part of feeder-policy-conf. Then I choose to change the name from MaxSize to capacity to avoid confusion with previous definition/place inside the xml. If you consider this is more confusing, I can change it to: container-pool-conf MaximumSize100/MaximumSize feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-pol icy feeder-policy-conf increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: jeudi 27 décembre 2001 19:14 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBOSS EJB Container Bug ?! So why was the MaxSize dropped and a feeder pool capacity config element added? The instance pool now grows to the maximum concurrent use count and capacity is a redundant item that should simply be the pool MaxSize value. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'jeff andrews' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 9:06 AM Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! Hi, On 2.4 the pool is never pre-feed with new instances, instead the pool is feed after the use of an instance. And depending on the x in 2.4.x, the pool may have a size of 1 all the time (no reuse at all). There were good reasons for that linked to locking, read archives if you want more infos. Check this : https://sourceforge.net/tracker/?func=detailaid=496326group_id=22866 a tid=381174 It will work on Jboss 2.4.4 latest cvs but the dtd/xml files were not changed, you need to change standardjboss.xml like this : container-pool-conf feeder-policyorg.jboss.ejb.plugins.TimedInstancePoolFeeder/feeder-p ol icy feeder-policy-conf capacity100/capacity increment10/increment period500/period /feeder-policy-conf /container-pool-conf Vincent. 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 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBOSS EJB Container Bug ?!
There is no way to currently block a request when the pool size is at its maximum. This is a behavior we should support so I will add a StrictMaximumSize flag to the instance pool configuration that when set to true will block requests when the pool is at its MaximumSize value. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: jeff andrews [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 11:41 AM Subject: RE: [JBoss-dev] JBOSS EJB Container Bug ?! And since I'm really more interested in the use of JBoss for promoting deployment of our application's solutions on it for our clients (for obviouse reasons, especially cost and ease of use), is there a way to turn this current (extended) concurrent JBoss handling off, and rather allow additional requests (to the available instances within a pool) to wait until (freed) bean instances are returned back to the pool..? Or is the only way for me to currently address it if via modifying the org.jboss.ejb.plugins.AbstractInstancePool.get() method that you have outlined below. If so, is there other methods that I should also be modifying, in order to insure that all bean's container types are behaving the same? Appreciate very much your thoughts and feedbacks. Thanks allot in advance. Regards; Jeff. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
