But that limits the container as a whole, not the specific piece of
logic that he wants to throttle. He may want to just, say, work on 5
tasks of this kind (since they're CPU expensive or something) but not
hamstring every request or every activity in the system.
I think he's right -- the container should block and wait (and
potentially time out) if it can't get a session bean instance, or a
thread in the thread pool, and the max bean pool should be respected,
since that's an intuitive, configured limitation.
Another solution would be to make an individual thread pool accessible
to the application, or assign it to an async bean (that way a
collection of beans can share the same thread pool).
In 3.x I couldn't, myself, find a way to get a WorkManager that I
could use, but it's not clear to me what the JNDI state would be of
one even if I could. In 3.x, a random thread had no JNDI access to
speak of and could not call an EJB, and I could find no way to get one
that did. I just punted and spammed it to an Async bean call, but I
don't have his throttling issues. I wanted to throttle but I gave up.
He can't even implement his own semaphore within the bean, because
threads would be consumed by those excess bean calls blocked and
waiting on the semaphore, rather than being queued up.
Perhaps he can use the Java EE 7 injectable Executor facilities. Would
that do the job? I don't know what control one has over that (i.e. can
he created a limited thread pool executor), or even if he's running GF
4.
What about MDBs? The pool limits are honored there right? I thought
they were. Seems awfully heavy weight to cheese around a thread pool
limit, but it might work.
On Mon, Mar 30, 2015 at 4: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.