[CONCURRENCY_EE_SPEC-18] Remove optional configuration attributes and consider standardize useful ones Created: 02/Nov/12  Updated: 02/Nov/12

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The spec currently lists configuration attributes for MES, MSES, ContextService and ManagedThreadFactory. However they are only examples and are not mandatory. We should remove example configuration attributes and consider standardizing some of the attributes and making those mandatory.

Suggested by Adam Bien.






[CONCURRENCY_EE_SPEC-19] Alignment with other Java EE specs such as Servlets, EJB, CDI Created: 02/Nov/12  Updated: 04/May/13

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JSR 236 spec possibly needs to be aligned with areas such CDI and asynchronous support in Servlets and EJB that were not yet available when the original JSR 236 spec was written.



 Comments   
Comment by kithouna [ 04/May/13 ]

Would be nice if @Asynchronous could optionally define the thread pool used for executing,





[CONCURRENCY_EE_SPEC-20] Support fork/join Created: 24/Nov/12  Updated: 27/Dec/12

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: braghest Assignee: anthony.lai
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fork-join, jsr-166

 Description   

It would be nice of running fork/join tasks in an Java EE container was supported. For that to happen a java.util.concurrent.ForkJoinPool or java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory (or both) need to be exposed. Exposing java.util.concurrent.ExecutorService and java.util.concurrent.ThreadFactory is not enough since java.util.concurrent.ForkJoinWorkerThread instances need to be created (subclass of java.lang.Thread).



 Comments   
Comment by anthony.lai [ 27/Dec/12 ]

hile I think this is a valuable suggestion, I am not sure we could fit this requirement into Java EE 7 time frame. We will have to defer this for the next
release, post Java EE 7.





[CONCURRENCY_EE_SPEC-38] Define Concurrency Resources Portably Created: 13/May/13  Updated: 01/Dec/14

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: reza_rahman Assignee: anthony.lai
Resolution: Unresolved Votes: 12
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It is currently not possible to define concurrency resources (context services, managed thread factories, managed executor services, managed scheduled executor services, etc) via standard annotations or XML. This is a potential usability issue, especially in cloud environments.

It may be very helpful to have portable annotations or XML for this, just like we now have for data sources and JMS resources.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.



 Comments   
Comment by arjan tijms [ 20/May/13 ]

Very much in favor of this!

Maybe the Java EE spec should even go one step further and set as a general rule that for every administered object introduced by a sub-spec there should be an equivalent portable solution (annotation and element in deployment descriptor). If such a solution is not provided there must be a really good (technical) reason given.

Would such a rule be an option?

Comment by f.rowe [ 04/Nov/14 ]

We attempted to address this issue by adding the ability to use annotations to inject the Default instances of the four services. Are you looking to configure the propagation performed by the ContextService or something else? Will you provide some examples with associated use cases?

Comment by arungupta [ 04/Nov/14 ]

Section 3.1.4.2 of the specification define several properties that can be used to configure ManagedExecutorService. It'll be great if these property names can be standardized, and supported in both annotation and web.xml.

Comment by arjan tijms [ 05/Nov/14 ]

What I think people are generally looking for is the ability to define and configure additional instances of the four services beyond the default ones and to configure the default ones in a portable way.

There are several use cases for this. The following holds for just the ability to define and configure the services from within an application archive:

  • Portability; definition and configuration of the four services is standardized. It now relies on vendor specific configuration.
  • Facilitating cloud deployments. In such scenarios the user may not have access to the container configuration and the only option is deploying an ear or war.

The ability to define more than one instance of any of the four services has as use case:

  • Preventing dead locks in a producer / consumer system. Here you often need a separate thread pool for the consumer and a separate one for the producer. I elaborated on this in my comment here: EJB_SPEC-9#345825

And example for the XML version in web.xml or application.xml could be:

   <managed-executor-service
      name="java:app/producerExecutorService"
      min-threads="10"
      max-threads="50"
      hung-task-threshold="50000"
      keepalive-time="10000"
   />

(an annotation variant would basically mirror this exactly)

And then inject this application defined instance via:

@Resource(lookup="java:app/producerExecutorService")
private ManagedScheduledExecutorService managedScheduledExecutorService;
Comment by nathan_r [ 07/Nov/14 ]

The configuration examples in the EE Concurrency spec are just examples of some possible ways a Java EE Provider Provider might go about providing configuration. If a configuration will be standardized, it will need to be more fully thought out.

What is appropriate for configuration at the application level ought to differ from what is appropriate for the server administrator to configure. Specifically, I would point out it's a bad practice for applications to define their own thread pools. Management of server resources like threads should not be the role of the application. While it is already possible for applications to get a thread pool by pooling threads obtained from a ManagedThreadFactory, for example, by supplying one any of the various methods of java.util.concurrent.Executors that create thread pools, we should avoid encouraging the practice any further by putting thread pool settings on application defined resources.

I certainly agree there is some value in applications being able to define managed executors in ways that are particular to the needs of the application.

  • The application knows better than anyone else which types of thread context it expects to use on tasks that it schedules. Fred proposed one way of addressing this under https://java.net/jira/browse/CONCURRENCY_EE_SPEC-36 which was to allow thread context propagation settings to be specified as execution properties (on a per task basis). This could alternately be accomplished at the level of the application by allowing an application to define a managed executor with specific thread context types.
  • While the application should not own pools of threads, it makes sense that an application might want to limit its use of threads. A "MaxConcurrency" setting would allow for that without actually forcing the creation of a new thread pool.
  • A hung task threshold could make sense for the application to define on a managed executor, or alternately as an execution property where it would be granular to the task itself.
Comment by arjan tijms [ 07/Nov/14 ]

Specifically, I would point out it's a bad practice for applications to define their own thread pools.

I would like to respectively disagree with this. It highly depends on the application type, the deployment scenario and the team setup.

In one team where I participated we developed a highly concurrent datafeeds processing system, internally using a consumer/producer pattern. We were in a small devops team and deployed a single application to a single AS. In that case it would not have made sense to hand over this job to any kind of server administrator (which incidentally wasn't there as a separate person). The separate thread pools that we used were all highly tuned and had relations such as one thread pool not allowed to have less threads than an other pool.

I know that you said to agree that there is value in applications being able to define executors, but in general if the platform limits developers out of an idea of enforcing best practices, then developers in practice will pretty much always find a way around it; use non-managed pools, embed an (other) application server with the archive, skip Java EE altogether, etc. I think none of these options are what we should strive for.

At most individual server products could put a limit on what the application is allowed to do, but I strongly belief it's not the Java EE platform's role to enforce what is a best practice for each and every kind of situation.

Comment by reza_rahman [ 24/Nov/14 ]

I am afraid I think Arjan is very much correct on this. While I understand and acknowledge the traditional J2EE ideas around application development vs. deployment vs. administration roles we've already crossed this bridge in Java EE 6 and Java EE 7 with @DataSourceDefinition, @JmsDestinationDefinition, @JmsConnectionFactoryDefinition and others in the same vein.
Indeed the Java EE 8 survey makes it clear that the community strongly desires being able to define even things like security providers within the application. Part of the equation is that other successful platforms like Spring, Ruby, Play, etc have been doing this sort of thing well for years. Another factor at play here is that movements like DevOps have largely blurred the lines between traditional boundaries of development and administration for many more progressive/agile organizations.

Getting this addressed will very likely be extremely well received by the community and help address what could otherwise be a continued portability, usability and flexibility gap in Java EE
application servers.

Comment by aheusingfeld [ 24/Nov/14 ]

reza_rahman I absolutely agree with you and Arjan! That's basically where I was heading with my mail to the users list. IMHO we certainly need to find a convenient, non-error-prone way for application developers to define the (semantic) resources their applications need including meaningful configuration defaults. Those configuration values will then have to be exposed via JMX e.g. in a ManagedExecutorService definition to make them changeable and checkable in production.

The main reason for me is that in the future I expect to see more of the scenarios where applications need to run in different environments e.g. on a local developer machine in a docker container, on a bare metal Q&A system and a fully virtualized pre-production or production environment. For sure those environments require different values for concurrency related configuration properties like our ExecutorServices. I'm talking of

  • number of incoming requests to handle
  • number of parallel calls to backend systems
  • number of available CPUs/ processors

all of which differ in the above mentioned environments.

but I strongly belief it's not the Java EE platform's role to enforce what is a best practice for each and every kind of situation.

Same for me. Probably none of us can predict which environments Java EE customers will have in 5-8 years and what constraints they bring along but it'd be great if the customers could still run Java EE 8 servers on them, wouldn't it?

Comment by nathan_r [ 01/Dec/14 ]

I'm clearly outnumbered, so I will try to go along with the proposal. But it needs more elaboration and it needs to be flexible enough for scenarios where the application wants the Java EE Product Provider to auto tune thread pooling, meaning it must avoid defaulting specific values for max and min.

We also need to consider that not every task submitted to an executor necessarily runs on a thread pool. For example, in the case of invokeAll(task1, task2), task1 might run on a pooled thread and task2 might run on the submitter's thread. Or maybe a task that hasn't started yet runs on the thread from which future.get() is attempted rather than a pooled thread. This is why establishing a PoolInfo:MaximumSize (section 3.1.4.2 example) doesn't address the usage pattern, whereas a Max Concurrency does.

Here are some more concrete examples of annotatively defining managed executors/thread factories/context service along these lines,

@ContextServiceDefinition(
name="java:comp/env/concurrent/MyContext",
context =

{ ContextServiceDefinition.CLASSLOADER_CONTEXT, ContextServiceDefinition.SECURITY_CONTEXT }

)

@ManagedExecutorDefinition(
name = "java:comp/env/concurrent/MyExecutor1",
contextService = "java:comp/env/concurrent/MyContext",
maxConcurrency = 20,
minConcurrency = 5
)

@ManagedScheduledExecutorDefinition(
name = "java:comp/env/concurrent/MyExecutor2",
contextService = "java:comp/env/concurrent/MyContext",
maxConcurrency = 10,
minConcurrency = 0
)

@ManagedThreadFactoryDefinition(
name="java:comp/env/concurrent/MyThreadFactory",
contextService="java:comp/env/concurrent/MyContext",
priority=5
)

We need more discussion about the proper granularity of hung-task-threshold. Is it better defined as a single value for all usage of an executor, or on a per task basis (via an execution property like ManagedTask.LONGRUNNING_HINT). Or should it be defined in both places, in which case the more granular setting takes precedence if specified.

The keepalive-time attribute seems like an implementation detail that would preclude otherwise valid implementations of EE Concurrency that choose not to use thread pools, or that choose to have multiple managed executors sharing thread pools. Maybe we could include a 'properties' attribute along the lines of what @DataSourceDefinition does for implementation specific properties.

I'm confused about "number of available CPUs/ processors" as a configurable setting. It would make more sense to me if we provided this information to the application rather than received it from the application. Was that the intention?

Are there other attributes that ought to be included?





[CONCURRENCY_EE_SPEC-31] Inconsistency in ManagedTaskListener#taskAborted javadoc Created: 23/May/13  Updated: 23/May/13

Status: Open
Project: concurrency-ee-spec
Component/s: 1.0 Errata
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following inconsistency in ManagedTaskListener JavaDoc regarding the ordering of taskAborted/taskDone notifications.

taskAborted method JavaDoc:
"This method may be called after taskDone()"

State Transition Diagram and examples B, C, D all show taskAborted happening BEFORE taskDone.

The sentence in the javadoc should be modified to

"This method may be called after taskSubmitted()"






[CONCURRENCY_EE_SPEC-32] ManagedThreadFactory javadoc and spec discrepancy regarding ManageableThread Created: 13/Sep/13  Updated: 03/Apr/14

Status: Open
Project: concurrency-ee-spec
Component/s: 1.0 Errata
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 3.4.4 of the spec says:
Threads returned by the newThread() method must implement the ManageableThread interface.

but javadoc says:
Threads returned from the newThread() method should implement the ManageableThread interface.

The spec is correct. The javadoc needs to be updated to say
Threads returned from the newThread() method must implement the ManageableThread interface.






[CONCURRENCY_EE_SPEC-34] Distributable MES Created: 14/Oct/13  Updated: 14/Oct/13

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Discuss whether we need to bring back distributable ManagedExecutorService in the next revision of the concurrency EE spec.

One question that was brought up is how one server instant can retrieve the Future to cancel a long-running task if the task was originally submitted by another server instance.






[CONCURRENCY_EE_SPEC-35] Java SE 8 Date and Time Support Created: 03/Apr/14  Updated: 03/Apr/14

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support for new Date and Time APIs in Java SE 8 in APIs in Trigger and LastExecution interfaces that currently use java.util.Date. Article on new APIs at http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html






[CONCURRENCY_EE_SPEC-36] Define new execution property constants in ManagedTask interface to support app portability Created: 23/Apr/14  Updated: 23/Apr/14

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: f.rowe Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes


 Description   

Consider adding additional execution property constants to the ManagedTask interface to allow control of the propagation of the required contexts, jndi, classloader and security. This will support application portability between app server providers.
For example, we could add:
static final String JNDI_CONTEXT_SOURCE - Execution property to be returned in getExecutionProperties() or ContextService.createContextualProxy() to control how the Java™ EE Product Provider propogates the JNDI context to the task or proxy method of contextual proxy object be executed in. Valid values are: "CURRENT_THREAD", "DEFAULT", and "NONE"
static final String CLASSLOADER_CONTEXT_SOURCE - Execution property to be returned in getExecutionProperties() or ContextService.createContextualProxy() to control how the Java™ EE Product Provider propogates the classloader context to the task or proxy method of contextual proxy object be executed in. Valid values are: "CURRENT_THREAD", "DEFAULT", and "NONE"
static final String SECURITY_CONTEXT_SOURCE - Execution property to be returned in getExecutionProperties() or ContextService.createContextualProxy() to control how the Java™ EE Product Provider propogates the security context to the task or proxy method of contextual proxy object be executed in. Valid values are: "CURRENT_THREAD", "DEFAULT", and "NONE"






[CONCURRENCY_EE_SPEC-37] The behavior of ScheduledFuture.get() with Trigger is not clearly stated in either spec or javadoc Created: 10/Jul/14  Updated: 05/Sep/14

Status: Open
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The behavior of calling get() on the ScheduledFuture returned by ManagedScheduledExecutorService.schedule() with a Trigger is not clearly defined in both the spec and javadoc.



 Comments   
Comment by f.rowe [ 05/Sep/14 ]

Consider a customer who creates a Trigger and uses ManagedScheduledExecutorService.schedule(Trigger) to achieve the equivalent of either of the ManagedScheduledExecutorService.scheduleAtFixedRate() or ManagedScheduledExecutorService.scheduleWithFixedDelay() methods. To avoid an inconsistency, we should define the behavior of ScheduledFuture.get() as being the same for all of these scenarios





[CONCURRENCY_EE_SPEC-33] Clarification in Trigger.getNextRunTime() javadoc Created: 30/Sep/13  Updated: 30/Sep/13

Status: Open
Project: concurrency-ee-spec
Component/s: 1.0 Errata
Affects Version/s: 1.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The javadoc for the taskScheduledTime parameter in Trigger.getNextRunTime() needs to be clarified. It currently says

taskScheduledTime - the date/time in which the task was scheduled using the ManagedScheduledExecutorService.schedule method.

It could potentially interpreted as the point in time at which the scheduled task should run, rather than the time at which the schedule method was invoked.

To clarify that it is the time at which the schedule method was invoked, the javadoc of the taskScheduledTime parameter should be updated to

taskScheduledTime - the date/time when the task was scheduled, that is, the date/time when the schedule method on the ManagedScheduledExecutorService was invoked.






Generated at Sat Apr 18 07:51:55 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.