You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by "Paul Turner (JIRA)" <ji...@apache.org> on 2013/03/03 18:33:12 UTC
[jira] [Reopened] (ETCH-258) Switch to using util.concurrent
instead of pre Java 5 threading constructs
[ https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Turner reopened ETCH-258:
------------------------------
Use of the CallerRunsPolicy in TodoManager in patch will mean that the caller thread will execute the PoolRunnable. Scott mentioned that this will cause problems due to possible deadlocking.
Reopened while I create a new RejectedExecutionHandler that will sleep when work queue is full as in original implementation .
> Switch to using util.concurrent instead of pre Java 5 threading constructs
> --------------------------------------------------------------------------
>
> Key: ETCH-258
> URL: https://issues.apache.org/jira/browse/ETCH-258
> Project: Etch
> Issue Type: Improvement
> Components: binding-java, general
> Reporter: Paul Turner
> Priority: Minor
> Fix For: 1.4
>
> Attachments: etch-20130301.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> thread creation is quite expensive and so a new thread per unit of work is also expensive, i propose to use util.concurrent threadpools in the java binding sub-project and enhance unit tests e.g. with countdown latches to ensure competing test threads start simeltanously and semaphore to throttle access to running units of work.
> affects FreePool, TodoManager and associated tests and possibly more classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Reopened] (ETCH-258) Switch to using util.concurrent
instead of pre Java 5 threading constructs
Posted by paul turner <pa...@gmail.com>.
Hi Robert,
As I said in the comment on the Jira, I originally used a bounded blocking
queue and a CallerRuns rejected execution handler policy which does a very
good job at resource management. The point of managing a threadpool in
this way is to make sure that producing threads do not swamp the system and
this is achieved by forcing them to do their own work when the threadpool
is saturated.
So, yes I have.
Now I see that the TodoManager *must* hand off to another thread for Todo
execution to eliminate deadlock risk and the approach I will use will mimic
the original functionality except I will use a Semaphore to throttle access
and force callers to wait.
Hope this answers your concerns, I'll be updating the patch in the next
couple of days.
best regards
Paul Turner
On Mon, Mar 4, 2013 at 4:59 PM, Robert Comer <we...@mac.com> wrote:
> the bit about todo manager sleeping a bit when the queue was full (and the
> queue being fixed length) was to prevent a jabbering or malicious client
> from consuming too many resources. have you preserved that quality?
>
> On Mar 4, 2013, at 5:21 AM, paul turner <pa...@gmail.com>
> wrote:
>
> > Hi Scott,
> >
> > I know how to fix it and I'll add a unit test to make sure the executing
> > thread is not the calling thread while I am doing it.
> >
> > best regards
> >
> > Paul
> >
> >
> > On Sun, Mar 3, 2013 at 6:33 PM, Paul Turner (JIRA) <ji...@apache.org>
> wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >>
> >> Paul Turner reopened ETCH-258:
> >> ------------------------------
> >>
> >>
> >> Use of the CallerRunsPolicy in TodoManager in patch will mean that the
> >> caller thread will execute the PoolRunnable. Scott mentioned that this
> >> will cause problems due to possible deadlocking.
> >>
> >> Reopened while I create a new RejectedExecutionHandler that will sleep
> >> when work queue is full as in original implementation .
> >>
> >>> Switch to using util.concurrent instead of pre Java 5 threading
> >> constructs
> >>>
> >>
> --------------------------------------------------------------------------
> >>>
> >>> Key: ETCH-258
> >>> URL: https://issues.apache.org/jira/browse/ETCH-258
> >>> Project: Etch
> >>> Issue Type: Improvement
> >>> Components: binding-java, general
> >>> Reporter: Paul Turner
> >>> Priority: Minor
> >>> Fix For: 1.4
> >>>
> >>> Attachments: etch-20130301.patch
> >>>
> >>> Original Estimate: 168h
> >>> Remaining Estimate: 168h
> >>>
> >>> thread creation is quite expensive and so a new thread per unit of work
> >> is also expensive, i propose to use util.concurrent threadpools in the
> java
> >> binding sub-project and enhance unit tests e.g. with countdown latches
> to
> >> ensure competing test threads start simeltanously and semaphore to
> throttle
> >> access to running units of work.
> >>> affects FreePool, TodoManager and associated tests and possibly more
> >> classes
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> If you think it was sent incorrectly, please contact your JIRA
> >> administrators
> >> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >>
>
>
Re: [jira] [Reopened] (ETCH-258) Switch to using util.concurrent
instead of pre Java 5 threading constructs
Posted by Robert Comer <we...@mac.com>.
the bit about todo manager sleeping a bit when the queue was full (and the queue being fixed length) was to prevent a jabbering or malicious client from consuming too many resources. have you preserved that quality?
On Mar 4, 2013, at 5:21 AM, paul turner <pa...@gmail.com> wrote:
> Hi Scott,
>
> I know how to fix it and I'll add a unit test to make sure the executing
> thread is not the calling thread while I am doing it.
>
> best regards
>
> Paul
>
>
> On Sun, Mar 3, 2013 at 6:33 PM, Paul Turner (JIRA) <ji...@apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Paul Turner reopened ETCH-258:
>> ------------------------------
>>
>>
>> Use of the CallerRunsPolicy in TodoManager in patch will mean that the
>> caller thread will execute the PoolRunnable. Scott mentioned that this
>> will cause problems due to possible deadlocking.
>>
>> Reopened while I create a new RejectedExecutionHandler that will sleep
>> when work queue is full as in original implementation .
>>
>>> Switch to using util.concurrent instead of pre Java 5 threading
>> constructs
>>>
>> --------------------------------------------------------------------------
>>>
>>> Key: ETCH-258
>>> URL: https://issues.apache.org/jira/browse/ETCH-258
>>> Project: Etch
>>> Issue Type: Improvement
>>> Components: binding-java, general
>>> Reporter: Paul Turner
>>> Priority: Minor
>>> Fix For: 1.4
>>>
>>> Attachments: etch-20130301.patch
>>>
>>> Original Estimate: 168h
>>> Remaining Estimate: 168h
>>>
>>> thread creation is quite expensive and so a new thread per unit of work
>> is also expensive, i propose to use util.concurrent threadpools in the java
>> binding sub-project and enhance unit tests e.g. with countdown latches to
>> ensure competing test threads start simeltanously and semaphore to throttle
>> access to running units of work.
>>> affects FreePool, TodoManager and associated tests and possibly more
>> classes
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
Re: [jira] [Reopened] (ETCH-258) Switch to using util.concurrent
instead of pre Java 5 threading constructs
Posted by paul turner <pa...@gmail.com>.
Hi Scott,
I know how to fix it and I'll add a unit test to make sure the executing
thread is not the calling thread while I am doing it.
best regards
Paul
On Sun, Mar 3, 2013 at 6:33 PM, Paul Turner (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/ETCH-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Paul Turner reopened ETCH-258:
> ------------------------------
>
>
> Use of the CallerRunsPolicy in TodoManager in patch will mean that the
> caller thread will execute the PoolRunnable. Scott mentioned that this
> will cause problems due to possible deadlocking.
>
> Reopened while I create a new RejectedExecutionHandler that will sleep
> when work queue is full as in original implementation .
>
> > Switch to using util.concurrent instead of pre Java 5 threading
> constructs
> >
> --------------------------------------------------------------------------
> >
> > Key: ETCH-258
> > URL: https://issues.apache.org/jira/browse/ETCH-258
> > Project: Etch
> > Issue Type: Improvement
> > Components: binding-java, general
> > Reporter: Paul Turner
> > Priority: Minor
> > Fix For: 1.4
> >
> > Attachments: etch-20130301.patch
> >
> > Original Estimate: 168h
> > Remaining Estimate: 168h
> >
> > thread creation is quite expensive and so a new thread per unit of work
> is also expensive, i propose to use util.concurrent threadpools in the java
> binding sub-project and enhance unit tests e.g. with countdown latches to
> ensure competing test threads start simeltanously and semaphore to throttle
> access to running units of work.
> > affects FreePool, TodoManager and associated tests and possibly more
> classes
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>