Guys,
What would MaxConcurrency mean?
A) on a bean class that contains N timeout methods, M async methods, and
that defines a LocalBean view and an interface-based view that a different?
A1) how the container would handle the timeout if there are
maxconcurrent bean instances in use:
A1.1) executed anyway
A1.2) skipped
A1.3) delayed (will there be a limit on the delay?)
A2) will async method be rejected or will it wait for an available
instance (it's async, so there is no requirement to start executing it
right away)?
A2.1) would we need to resurrect the @AsynchronousTimeout to
solve A2?
B) on a method - would it mean that only instances executing this method
count? This will require the EJB container to track not only instances
but the exact methods that are being invoked...
thanks,
-marina
Adam Bien wrote:
> Hi Carlo,
> On 08.05.2012, at 10:27, Carlo de Wolf wrote:
>
>
>> I still don't know what is the issue exactly. :-)
>>
>> I guess you mean that EJBs can be invoked concurrently from other thread pools. (Servlet, remote etc)
>>
> No, absolutely not. I just want to limit the concurrent requests per EJB type.
>
>> In that case max-concurrency might be the wrong concept. It is more the thread pool size attached to the EJB. (Similar to the amount of worker threads on a RAR vs the amount of instances of a MDB.)
>> Those bits are differently implemented across vendors.
>>
>
> But max-pool-size would work.
>
>
> And: my proposal started with @Asynchronous, you suggested to widen the concept to everything, what I appreciate :-)
>
> thanks!,
>
> adam
>
>> Carlo
>>
>> On 05/08/2012 06:56 AM, Adam Bien wrote:
>>
>>> Hi Carlo,
>>>
>>> you are right. Singleton and No-Async methods are an issue as well, however having @Asynchronous without throttling is almost a bug.
>>>
>>> I would really appreciate a widening of my proposal to Singletons and No-Async methods,
>>>
>>> thanks,
>>>
>>> adam
>>>
>>>
>>> On 04.05.2012, at 10:44, Carlo de Wolf wrote:
>>>
>>>
>>>> Adam,
>>>>
>>>> The proposal doesn't mimic the original one: http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-04/message/15
>>>>
>>>> Why are non-async& Singleton invocations an issue?
>>>>
>>>> Carlo
>>>>
>>>> On 05/03/2012 09:06 PM, Marina Vatkina wrote:
>>>>
>>>>> Experts,
>>>>>
>>>>> Do you:
>>>>> a) agree with the proposal
>>>>> b) disagree with the proposal
>>>>> c) have another proposal (please provide one)
>>>>> d) would like to modify the proposal (be specific in this case)
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [ejb-spec issues] [JIRA] Commented: (EJB_SPEC-9) Introduction of @MaxConcurrency annotation
>>>>> Date: Thu, 3 May 2012 05:24:22 +0000 (GMT+00:00)
>>>>> From: abien (JIRA)<jira-no-reply_at_java.net>
>>>>> Reply-To: issues_at_ejb-spec.java.net
>>>>> To: issues_at_ejb-spec.java.net
>>>>>
>>>>>
>>>>>
>>>>> [ http://java.net/jira/browse/EJB_SPEC-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338919#action_338919 ]
>>>>> abien commented on EJB_SPEC-9:
>>>>> ------------------------------
>>>>>
>>>>> Proposal:
>>>>>
>>>>> @MaxConcurrency annotation as well as the<max-concurrency> element in the ejb-jar.xml specify the maximum number of requests handled by a given bean class. After the configured number of concurrent requests is reached, the container throws a javax.ejb.MaxConcurrencyExceededException. A @MaxConcurrency value of -1 indicates an infinite amount of concurrency. Max Concurrency applies on classes, to specify per bean concurrency, as well as @Asynchronous methods. Max Concurrency is neither applicable on synchronous methods [I guess without this restriction, the feature would be harder to implement by the container provider], nor on @Singleton beans.
>>>>>
>>>>>
>>>>>
>>>>> public class MaxConcurrencyExceededException extends EJBException{
>>>>>
>>>>> public MaxConcurrencyExceededException(String message, Exception ex) {
>>>>> super(message, ex);
>>>>> }
>>>>>
>>>>> public MaxConcurrencyExceededException(Exception ex) {
>>>>> super(ex);
>>>>> }
>>>>>
>>>>> public MaxConcurrencyExceededException(String message) {
>>>>> super(message);
>>>>> }
>>>>>
>>>>> public MaxConcurrencyExceededException() {
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> @Documented
>>>>> @Target({ElementType.METHOD, ElementType.TYPE})
>>>>> @Retention(RetentionPolicy.RUNTIME)
>>>>> public @interface MaxConcurrency {
>>>>> /**
>>>>> * Specifies the maximum concurrency of an EJB or asynchronous method<br/>
>>>>> * -1 is the default. A negative value means infinite number of requests.
>>>>> */
>>>>> int value() default -1;
>>>>> }
>>>>>
>>>>> Default: -1 infinite.
>>>>>
>>>>>
>>>>>> Introduction of @MaxConcurrency annotation
>>>>>> ------------------------------------------
>>>>>>
>>>>>> Key: EJB_SPEC-9
>>>>>> URL: http://java.net/jira/browse/EJB_SPEC-9
>>>>>> Project: ejb-spec
>>>>>> Issue Type: New Feature
>>>>>> Affects Versions: 3.2
>>>>>> Reporter: abien
>>>>>> Attachments: MaxConcurrency.zip
>>>>>>
>>>>>>
>>>>>> Currently proprietary max-pool-size settings are used to control the max concurrency of an application and so to prevent overloading the application server.
>>>>>> We could abstract the intended behavior into an annotation:
>>>>>> @Target(value = {ElementType.METHOD, ElementType.TYPE})
>>>>>> @Retention(value = RetentionPolicy.RUNTIME)
>>>>>> public @interface MaxConcurrency {
>>>>>> public int value() default 30;
>>>>>> }
>>>>>> We could provide more generic annotation like:
>>>>>> @Target(value = {ElementType.METHOD, ElementType.TYPE})
>>>>>> @Retention(value = RetentionPolicy.RUNTIME)
>>>>>> public @interface Concurrency {
>>>>>> public int max() default 30;
>>>>>> }
>>>>>> to support future extensions. This functionality should be available for EJB 3.2 and CDI.
>>>>>>
>
> workshops.adam-bien.com
> blog.adam-bien.com
> about.adam-bien.com
>
> Author of:
> "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>