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