dev@glassfish.java.net

[gf-dev] Re: EJB pool

From: Will Hartung <willh_at_mirthcorp.com>
Date: Tue, 31 Mar 2015 11:59:28 -0700

If you're using 4.1, then you might want to look at
ManagedExecutorService. These are basically container managed thread
pools that you can configure explicitly in GF.

I have not used them, I don't know what/who's JNDI they inherit, so I
don't know what EJBs they can look up, or how that is handled.

But if you can get them to work, it gives you the ability to create
thread pools, and then, ideally, tasks can call EJB methods directly.



On Tue, Mar 31, 2015 at 11:43 AM, Janario Oliveira
<janarioliver_at_gmail.com> wrote:
> The example I sent was not from a http request but after some executions and
> involves others EJBs.
> As I see the container should support fine tuning to balance the processes.
>
> By the way I'm using the latest version of GlassFish, 4.1
>
> On Mon, Mar 30, 2015 at 8:36 PM, Mahesh Kannan <Mahesh.Kannan_at_oracle.com>
> wrote:
>>
>> Since this is a local bean, I am assuming that you are accessing it from a
>> Servlet. You can try configuring the "thread-pool" configurations or any
>> web container specific settings that limits the number of requests.
>>
>>
>>
>> On 3/30/15 3:36 PM, Janario Oliveira wrote:
>>
>> The problem is I don't want a heavy process to "hijack" the container. So
>> that's why I'm limiting the async pool, to make sure that at most x
>> instances will be executing at a given time. The way that GlassFish works
>> now defeats the purpose of what I'm trying to achieve. How can I limit the
>> number of executing async instances for a given case then?
>>
>> On Mon, Feb 9, 2015 at 6:16 PM, Mahesh Kannan <Mahesh.Kannan_at_oracle.com>
>> wrote:
>>>
>>>
>>> On 02/09/2015 08:31 AM, Janario Oliveira wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I am trying to configure an ejb bean pool. But it is not working.
>>>>
>>>> I have one stateless (AsyncService) and I have added
>>>> glassfish-ejb-jar.xml in WEB-INF
>>>>
>>>> glassfish-ejb-jar.xml:
>>>> <sun-ejb-jar>
>>>> <enterprise-beans>
>>>> <ejb>
>>>> <ejb-name>AsyncService</ejb-name>
>>>> <bean-pool>
>>>> <steady-pool-size>2</steady-pool-size>
>>>> <resize-quantity>1</resize-quantity>
>>>> <max-pool-size>5</max-pool-size>
>>>> <pool-idle-timeout-in-seconds>300</pool-idle-timeout-in-seconds>
>>>> </bean-pool>
>>>> </ejb>
>>>> </enterprise-beans>
>>>> </sun-ejb-jar>
>>>>
>>>> It should limit AsyncService in maximum 5 instances. I've added a
>>>> PostConstruct method to log creations.
>>>>
>>>> AsyncService:
>>>> @Stateless
>>>> public class AsyncService {
>>>> @PostConstruct
>>>> private void init() { System.out.println("Contruct AsyncService"); }
>>>> @Asynchronous
>>>> public Future<LocalDateTime> asyncTest() {...}
>>>> }
>>>>
>>>>
>>>> Calling the asyncTest in a loop of 15 times it creates more the maximum
>>>> configured.
>>>
>>>
>>> This is by design. We didn't want the incoming requests to be blocked
>>> just because
>>> there are not enough stateless EJBs in the pool. So, when an
>>> incoming request
>>> arrives and if there are no beans in the pool, the container will
>>> create a new
>>> bean instance. However, the pool will hold only <max-pool-size>
>>> beans. Bean
>>> instances that are created in excess of <max-pool-size> will be
>>> destroyed when
>>> the request completes.
>>>
>>>
>>>>
>>>> Is there another way to configure that or are my configurations wrong?
>>>
>>>
>>
>>
>

-- 
This message, and any documents attached hereto, may contain confidential 
or proprietary information intended only for the use of the addressee(s) 
named above or may contain information that is legally  privileged. If you 
are not the intended addressee, or the person responsible for delivering it 
to the intended addressee, you are hereby notified that reading, 
disseminating, distributing or copying this message is strictly prohibited. 
If you have received this message by mistake, please immediately notify us 
by replying to the message and delete the original message and any copies 
immediately thereafter.  Thank you for your cooperation.