[MAGNOLIA-2427] replace custom thread pool with library Created: 12/Oct/08  Updated: 23/Jan/13  Resolved: 20/Jan/09

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 3.6.3
Fix Version/s: 4.0

Type: Improvement Priority: Minor
Reporter: Philippe Marschall Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: java5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ThreadPool.EDU.oswego.patch     Text File ThreadPool.java.patch    
Issue Links:
dependency
depends upon MGNLXAA-15 Change dependency to Magnolia 4.0 due... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

The module exchange-simple uses it's own thread pool instead of a library. There is no need for this since there are mature, stable, tested and debugged libraries available that do this. The attached patch uses the backport of java.util.concurrent that as an easy migration path to JDK 1.5 in Magnlia 4.

The patch also removes two unused variables and corrects some indentation issues.



 Comments   
Comment by Jan Haderka [ 12/Oct/08 ]

Excellent. Thanks very much. I'll have a look and try to apply it soon.

Comment by Jan Haderka [ 14/Oct/08 ]

Hi Philippe,
the patch looks great, but at this point we would like to not introduce yet another library for handling concurrency (we already use edu.oswego.* at various places). We will revisit this and apply (And modify to use java.util.concurrent) once we are dropping 1.4 support and moving to 1.5.

Comment by Philippe Marschall [ 14/Oct/08 ]

I'll rewrite the patch to use edu.oswego.* then.

Comment by Jan Haderka [ 14/Oct/08 ]

Thanks a lot.

Comment by Philippe Marschall [ 14/Oct/08 ]

Use original util.concurrent instead of backport of JSR 166

Comment by Philippe Marschall [ 14/Oct/08 ]

Ok, here we go again. Some notes:

  1. The thread pool has an unbounded job queue. Maybe it would make sense to limit it to something like 500 so that jobs can't be produced too fast.
  2. The thread pool lazily allocates 10 Threads that don't time out. Maybe it would make sense to tweak that as well and have at minimum one thread and at most 10.
  3. If for some reason (like the current thread being interrupted) a job can't be added to the pool an Exchange exception is thrown.
Comment by Jan Haderka [ 20/Jan/09 ]

Done as of r21484. Thanks again for the patch.

Generated at Mon Feb 12 03:36:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.