<< Back to previous view

[CONCURRENCY_EE_SPEC-13] Thread Shutdown issue Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

According to the Javadoc at [1], support for managed thread factories is intended. I am wondering if any particular shutdown mechanism has been specified? How will the container tear down threads associated with a given component?

I would like to suggest that we specify a thread base class or interface for managed threads, which includes an isShutdown() method which would return a flag which is set when the thread is requested to terminate. The thread should also be interrupted at this time.

I would also suggest that threads started after component shutdown was initiated should be allowed to run, but they should start with an interrupted status and their shutdown flag set.

[1] http://concurrency-ee-spec.java.net/javadoc/index.html?javax/enterprise/concurrent/ManagedThreadFactory.html



 Comments   
Comment by anthony.lai [ 07/Aug/12 07:05 PM ]

Added new interface ManageableThread and new helper method ManagedExecutors.isCurrentThreadShutdown().

Updated section 3.4.4 with ManagedThreadFactory shutdown details.





[CONCURRENCY_EE_SPEC-7] Section 4 Managed Object should be optional Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

Section 4 Managed Object should be optional






[CONCURRENCY_EE_SPEC-6] Remove following requirements from section 3.5.1 Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

Remove the following requirements from section 3.5.1
" - Tasks submitted to the master executor are owned by the executor instance. If the master executor becomes unavailable, the submitted tasks are cancelled.

  • All tasks are not considered to be idempotent. If a slave executor becomes unavailable, all Futures for the tasks submitted to that executor that have not yet started will be cancelled.
  • If a slave executor becomes unavailable, and the task has started, the result of the task's Future will throw a javax.enterprise.concurrent.ExecutorNotAvailableException exception. "

The Distributed ManagedExecutorService/ManagedScheduledExecutorService should be free to submit to a different "slave" or to run the task itself.






[CONCURRENCY_EE_SPEC-5] Distributable ManagedExeutorService should be optional Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

Distributable ManagedExeutorService should be optional






[CONCURRENCY_EE_SPEC-4] Remove component-managed from the spec Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

Remove component-managed from the spec
We should remove component-managed from the spec, because this function is duplicate of what a user would get by supplying a ManagedThreadFactory to a Java SE executor service.

Regarding the sentence "If the threads are pooled, the overhead of reusing a thread disappears since the context does not have to change the thread's context." - This statement isn't entirely accurate. Think of security context, where different users are running the same component. It would be an error to keep reusing the context of user1 on pooled threads for user2 and user3 who are also using the component. The the security context will be all wrong. This is another reason why we want to get rid of Component-Managed Executor. If we instead let it be the component's responsibility to get this behavior by supplying a ManagedThreadFactory to a Java SE executor service, then it will be clear to the component exactly what they're doing.






[CONCURRENCY_EE_SPEC-3] Contextual invocation points listed in section 2.3.1 should be made optional Created: 31/Jul/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

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

Tags:
Participants: anthony.lai

 Description   

The following contextual invocation points listed section 2.3.1 should be made optional
ManagedTaskListener

  • taskAborted()
  • taskSubmitted()
  • taskStarting()
    Trigger
  • getNextRunTime()
  • skipRun()
    We should make all of these optional as contextual invocation points. It seems inefficient to be propagating context to all of these by default, which I suspect in a lot of cases won't be used. Let the ManagedExecutorService/ManagedScheduledExecutorService provide its own config options to control this as an optional behavior.


 Comments   
Comment by anthony.lai [ 07/Aug/12 06:59 PM ]

Updated section 2.3.1 to make callback methods as optional contextual invocation points. Added new configuration attribute contextual-callback to enable optional contextual invocation points.





[CONCURRENCY_EE_SPEC-2] Avoid JCA acronym Created: 05/Jun/12  Updated: 21/Nov/12  Resolved: 07/Aug/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Aug 6 2012

Type: Task Priority: Trivial
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: anthony.lai

 Description   

Avoid the use of the acronym JCA in spec.
Probably move the Connectors spec reference to 1.6.






Generated at Fri Apr 18 15:43:25 UTC 2014 using JIRA 4.0.2#472.