users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: [Fwd: [ejb-spec issues] [JIRA] Commented: (EJB_SPEC-9) Introduction of @MaxConcurrency annotation]

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Tue, 8 May 2012 19:49:35 -0400

The way Resin implements this is that there is an access wait controlled by
the existing @AccessTimeout annotation. All access to the bean is controlled
the same way. It would be good to enable this at the method level.

> -----Original Message-----
> From: Marina Vatkina [mailto:marina.vatkina_at_oracle.com]
> Sent: Tuesday, May 08, 2012 5:17 PM
> To: jsr345-experts_at_ejb-spec.java.net
> Subject: [jsr345-experts] Re: [Fwd: [ejb-spec issues] [JIRA] Commented:
> (EJB_SPEC-9) Introduction of @MaxConcurrency annotation]
>
> 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"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >