Sorry, and here is the test code. First the main class (only change is
adding the MinSize property):
package org;
import java.util.Properties;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import javax.ejb.embeddable.EJBContainer;
import javax.naming.Context;
import javax.naming.NamingException;
public class Main {
public static void main(String[] args) throws
InterruptedException, NamingException {
final EJBContainer c = EJBContainer.createEJBContainer(new
Properties() {{
setProperty("Default Stateless Container.MaxSize", "100");
setProperty("Default Stateless Container.MinSize", "100");
}});
final Context ctx = c.getContext();
final TestBean bean =
TestBean.class.cast(ctx.lookup("java:global/test/TestBean"));
final ExecutorService es = Executors.newFixedThreadPool(100);
for (int i = 0; i < 100; i++) {
es.submit(new Runnable() {
@Override
public void run() {
bean.foo();
}
});
}
es.shutdown();
es.awaitTermination(1, TimeUnit.DAYS);
c.close();
}
}
And the bean, only change is added the @Asynchronous annotation:
package org;
import java.util.concurrent.atomic.AtomicInteger;
import javax.ejb.Stateless;
import javax.ejb.EJB;
import javax.ejb.Asynchronous;
@Stateless
public class TestBean {
private static final AtomicInteger id = new AtomicInteger(1);
private int i = id.getAndIncrement();
private boolean done = false;
@Asynchronous
public void foo() {
if (!done) {
System.out.println(">>> " + i);
}
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
On Tue, Jan 7, 2014 at 3:03 PM, Stuart Easterling <
[email protected]> wrote:
>
> I believe I may have identified the source of the problem.
>
> Romain, if you add the annotation @Asynchronous to your foo() business
> method in TestBean it reproduces the behavior I have been having.
>
> In addition, with this change, the container only instantiates three beans
> for the pool.
>
> So if I add the line:
>
> setProperty("Default Stateless Container.MinSize", "100");
>
> then 100 beans are instantiated, but only three beans are used (the last
> three instantiated), rather than all the beans in the pool.
>
> Can you (or someone) let me know if you can reproduce this?
>
> If so, this seems to be a problem with the container? If a particular
> business method is asynchronous it should not mean that the pool is not
> fully utilized. (In this case, if the three beans are in use then access to
> a bean instance is blocked until one of the three beans is available.)
>
> Or is there a reason for this behavior (or is it configurable)?
>
> The output is:
>
> >>> 100
> >>> 99
> >>> 98
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 99
> >>> 98
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 100
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 100
> >>> 99
> >>> 98
> >>> 99
> >>> 100
> >>> 99
> >>> 98
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 99
> >>> 98
> >>> 100
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 98
> >>> 100
> >>> 99
> >>> 100
> >>> 98
> >>> 99
> >>> 100
> >>> 98
>
> Best,
> Stuart
>
>
> On Tue, Jan 7, 2014 at 11:48 AM, Stuart Easterling <
> [email protected]> wrote:
>
>> I should also determine if the implementation of commonsj.WorkManager
>> that I am using (commonj.myfoo.de) is -- for some reason -- the problem.
>> Will update soon.
>> Best,
>> Stuart
>>
>>
>> On Tue, Jan 7, 2014 at 11:38 AM, Stuart Easterling <
>> [email protected]> wrote:
>>
>>> Update: I have successfully run Romain's code and it performs as
>>> advertised.
>>>
>>> However, when I deploy Romain's bean to the Tomee server, the pool has
>>> the same problems as before: only one bean is provided to the client by the
>>> container.
>>>
>>> As in the output looks like:
>>>
>>> >>> 35
>>> >>> 35
>>> >>> 35
>>>
>>> .. and so on.
>>>
>>> Log output in the constructor indicates 100 beans are instantiated. The
>>> tomee log output says:
>>>
>>> INFO: Created Ejb(deployment-id=foo, ejb-name=TestBean, container=foo)
>>>
>>> and
>>>
>>> INFO: Started Ejb(deployment-id=foo, ejb-name=TestBean, container=foo)
>>>
>>> My deployment info is as follows:
>>>
>>> In tomee.xml I have only:
>>>
>>>
>>> <Container id="foo" type="STATELESS">
>>> minSize = 100
>>> maxSize = 100
>>> </Container>
>>>
>>> In ejb-jar.xml:
>>>
>>> <session>
>>> <ejb-name>TestBean</ejb-name>
>>> <ejb-class>org.TestBean</ejb-class>
>>> <session-type>Stateless</session-type>
>>> <transaction-type>Container</transaction-type>
>>> </session>
>>>
>>>
>>> Best,
>>> Stuart
>>>
>>>
>>> On Tue, Jan 7, 2014 at 11:01 AM, Stuart Easterling <
>>> [email protected]> wrote:
>>>
>>>> Hi Howard, thanks for your reply. To clarify, the singleton bean is not
>>>> the issue: that is working fine, and as expected there is only one bean
>>>> instantiated. I only mentioned this to clarify that I do have a workaround
>>>> for now. : )
>>>>
>>>> The problem I am having is with the stateless session bean pool. For a
>>>> pool of 100 instances, the container is only making the last 3 instantiated
>>>> beans available to me (for details see my previous post).
>>>>
>>>> In addition, the differences between the behavior of my test
>>>> implementation and Romain's is odd: it seems the two containers are
>>>> behaving quite differently as far as bean pooling, and I am wondering if
>>>> this might help explain the problem with my container/pool.
>>>>
>>>> Best,
>>>> Stuart
>>>>
>>>>
>>>> On Tue, Jan 7, 2014 at 10:46 AM, Howard W. Smith, Jr. <
>>>> [email protected]> wrote:
>>>>
>>>>> Stuart,
>>>>>
>>>>> On Tue, Jan 7, 2014 at 10:03 AM, Stuart Easterling <
>>>>> [email protected]> wrote:
>>>>>
>>>>> > Hi Romain, I think I may need to do that (my current workaround is
>>>>> to use a
>>>>> > singleton bean and many threads, but I'd like to get my pool working
>>>>> too :
>>>>> > ).
>>>>> >
>>>>>
>>>>> you seem to want to know the difference between the behavior/execution
>>>>> of
>>>>> your code and Romain's code. you mentioned 'singleton bean and many
>>>>> threads', above. did you share your singleton bean code already in this
>>>>> thread? sorry if i missed that.
>>>>>
>>>>> i'm asking/responding, as you asked if anyone seen this behavior
>>>>> before (in
>>>>> their app). the only time, I've seen similar behavior is with my
>>>>> singleton
>>>>> beans... the latest (or only) instantiated singleton bean...is
>>>>> used/referenced.
>>>>>
>>>>
>>>>
>>>
>>
>
