Well that depends.
For an ASYNC bean, I would think that the container would simply queue
the request and it would be processed in "due time". If the async
QUEUE is full, then it would throw an immediate exception. Async task
are, idiomatically, allowed to "wait their turn", they're async after
all.
This is in contrast to a request from, say, a Connection Pool. Since
the connection is needed "immediately", this kind of request would
simply block, and throw an exception on timeout. This is how those
work now.
The managed Executor Service make all this explicit: how many threads
can run, how deep the queue for pending requests is.
But the JNDI environment is painfully underspecified.
But that suggests the Executor Services some what obsolate the
elegance of async methods. Seems like a small leap to allow the
Deployer to associate beans (if not methods) with particular thread
pools within the container, since the thread pools are now a first
class Java EE managed resource, rather than an implied, container
specific resource as before.
Regards,
Will Hartung
(willh_at_mirthcorp.com)
On Tue, Mar 31, 2015 at 12:03 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> If there was an actual limit, what would you want to happen when the limit
> was reached? Would you want an exception to be thrown to the client? Or do
> you expect the request to block and wait for an instance to be free? How
> long should it wait?
>
> Janario Oliveira wrote on 03/31/15 11:43:
>
> 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.