You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Jaroslaw Cwiklik <ui...@gmail.com> on 2009/05/11 16:10:50 UTC

Re: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for CPMEngine

Ahh, now I understand. Yes, I agree that the ProcessingUnit as an interface
would be a better choice to provide cleaner approach for customizing the
code. The customization of PUs was added late in the development cycle of
the CPM, specifically to support single threaded Processing. The initial
design did not allow for customization of PUs. So the current ProcessingUnit
class should probably be renamed to ProcessingUnitImpl and a new
ProcessingUnit interface should be added. Does not seem like a lot of work.

Jerry Cwiklik

On Fri, May 8, 2009 at 6:39 PM, <ma...@thomsonreuters.com> wrote:

> Jerry,
> Let see what I mean:
>
> CPMEngine is references 'ProcessingUnit' which is in turn not the
> interface, but a class
>
> - 1: In order to plug custom 'ProcessingUnit' you have to subclass from
> 'ProcessingUnit'
> - 2: A good candidate to override is 'processNext', but it this calls:
> private handleEOFToken(), even if one what to duplicate this
>        handleEOFToken calls cpm.processingUnitShutdown, package scope
> function in CPMEngine.
> - 3: There are no good clean point to override without to be exposed to all
> that processing code.
>
> Ideally it needs well defined points that can be easily overridden with the
> maximum control over the CAS/CasData flow, that is
>        CAS/CasData,CasData/CAS conversions and calling CasProcessor.
>
>
> -----Original Message-----
> From: Jerry Cwiklik (JIRA) [mailto:uima-dev@incubator.apache.org]
> Sent: Friday, May 08, 2009 7:56 AM
> To: uima-dev@incubator.apache.org
> Subject: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for
> CPMEngine
>
>
>    [
> https://issues.apache.org/jira/browse/UIMA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707361#action_12707361]
>
> Jerry Cwiklik commented on UIMA-1338:
> -------------------------------------
>
> Not sure what you mean by
>
> "... boundaries between CPMEngine and ProcessingUnit not clearly defined."
>
> The custom ProcessingUnit can be plugged in (as you noted) via a system
> param. The CPMEngine creates as many instances of custom ProcessingUnits as
> there are processing threads defined in the CPE descriptor:
>
>
> if (System.getProperty("PROCESSING_PIPELINE_IMPL") != null) {
>          String puClass = System.getProperty("PROCESSING_PIPELINE_IMPL");
>          try {
>            processingUnits[i] = producePU(puClass);
>            processingUnits[i].setInputQueue(workQueue);
>            processingUnits[i].setOutputQueue(outputQueue);
>            processingUnits[i].setCPMEngine(this);
>          } catch (Exception e) {
>
> All PUs share the same Input and Output queues. Think of PUs as Worker
> threads that share the load. CPMEngine creates them and manages lifecycle of
> PUs.
>
>
> > Custom plugable ProcessingUnit for CPMEngine
> > --------------------------------------------
> >
> >                 Key: UIMA-1338
> >                 URL: https://issues.apache.org/jira/browse/UIMA-1338
> >             Project: UIMA
> >          Issue Type: Improvement
> >          Components: Collection Processing
> >            Reporter: Maksim Likharev
> >            Priority: Minor
> >   Original Estimate: 504h
> >  Remaining Estimate: 504h
> >
> > Kind of intended this way through "PROCESSING_PIPELINE_IMPL" system
> param, but boundaries between CPMEngine and ProcessingUnit not clearly
> defined.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
>

Re: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for CPMEngine

Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
Maksim, just attach patches to the JIRA and someone will commit them.

Jerry Cwiklik


On Mon, May 11, 2009 at 3:31 PM, <ma...@thomsonreuters.com> wrote:

> Jerry,
> it's not a big work at all, besides I'm doing custom PU for my own
> purposes and can do this modification as well.
>
> Any special instructions about committing changes other than described
> on UIMA Apache web?
>
> Thanks.
>
> -----Original Message-----
> From: Jaroslaw Cwiklik [mailto:uimaee@gmail.com]
> Sent: Monday, May 11, 2009 7:11 AM
> To: uima-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (UIMA-1338) Custom plugable
> ProcessingUnit for CPMEngine
>
> Ahh, now I understand. Yes, I agree that the ProcessingUnit as an
> interface
> would be a better choice to provide cleaner approach for customizing the
> code. The customization of PUs was added late in the development cycle
> of
> the CPM, specifically to support single threaded Processing. The initial
> design did not allow for customization of PUs. So the current
> ProcessingUnit
> class should probably be renamed to ProcessingUnitImpl and a new
> ProcessingUnit interface should be added. Does not seem like a lot of
> work.
>
> Jerry Cwiklik
>
> On Fri, May 8, 2009 at 6:39 PM, <ma...@thomsonreuters.com>
> wrote:
>
> > Jerry,
> > Let see what I mean:
> >
> > CPMEngine is references 'ProcessingUnit' which is in turn not the
> > interface, but a class
> >
> > - 1: In order to plug custom 'ProcessingUnit' you have to subclass
> from
> > 'ProcessingUnit'
> > - 2: A good candidate to override is 'processNext', but it this calls:
> > private handleEOFToken(), even if one what to duplicate this
> >        handleEOFToken calls cpm.processingUnitShutdown, package scope
> > function in CPMEngine.
> > - 3: There are no good clean point to override without to be exposed
> to all
> > that processing code.
> >
> > Ideally it needs well defined points that can be easily overridden
> with the
> > maximum control over the CAS/CasData flow, that is
> >        CAS/CasData,CasData/CAS conversions and calling CasProcessor.
> >
> >
> > -----Original Message-----
> > From: Jerry Cwiklik (JIRA) [mailto:uima-dev@incubator.apache.org]
> > Sent: Friday, May 08, 2009 7:56 AM
> > To: uima-dev@incubator.apache.org
> > Subject: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit
> for
> > CPMEngine
> >
> >
> >    [
> >
> https://issues.apache.org/jira/browse/UIMA-1338?page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707361#
> action_12707361]
> >
> > Jerry Cwiklik commented on UIMA-1338:
> > -------------------------------------
> >
> > Not sure what you mean by
> >
> > "... boundaries between CPMEngine and ProcessingUnit not clearly
> defined."
> >
> > The custom ProcessingUnit can be plugged in (as you noted) via a
> system
> > param. The CPMEngine creates as many instances of custom
> ProcessingUnits as
> > there are processing threads defined in the CPE descriptor:
> >
> >
> > if (System.getProperty("PROCESSING_PIPELINE_IMPL") != null) {
> >          String puClass =
> System.getProperty("PROCESSING_PIPELINE_IMPL");
> >          try {
> >            processingUnits[i] = producePU(puClass);
> >            processingUnits[i].setInputQueue(workQueue);
> >            processingUnits[i].setOutputQueue(outputQueue);
> >            processingUnits[i].setCPMEngine(this);
> >          } catch (Exception e) {
> >
> > All PUs share the same Input and Output queues. Think of PUs as Worker
> > threads that share the load. CPMEngine creates them and manages
> lifecycle of
> > PUs.
> >
> >
> > > Custom plugable ProcessingUnit for CPMEngine
> > > --------------------------------------------
> > >
> > >                 Key: UIMA-1338
> > >                 URL: https://issues.apache.org/jira/browse/UIMA-1338
> > >             Project: UIMA
> > >          Issue Type: Improvement
> > >          Components: Collection Processing
> > >            Reporter: Maksim Likharev
> > >            Priority: Minor
> > >   Original Estimate: 504h
> > >  Remaining Estimate: 504h
> > >
> > > Kind of intended this way through "PROCESSING_PIPELINE_IMPL" system
> > param, but boundaries between CPMEngine and ProcessingUnit not clearly
> > defined.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
> >
>

RE: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit for CPMEngine

Posted by ma...@thomsonreuters.com.
Jerry,
it's not a big work at all, besides I'm doing custom PU for my own
purposes and can do this modification as well.

Any special instructions about committing changes other than described
on UIMA Apache web?

Thanks.

-----Original Message-----
From: Jaroslaw Cwiklik [mailto:uimaee@gmail.com] 
Sent: Monday, May 11, 2009 7:11 AM
To: uima-dev@incubator.apache.org
Subject: Re: [jira] Commented: (UIMA-1338) Custom plugable
ProcessingUnit for CPMEngine

Ahh, now I understand. Yes, I agree that the ProcessingUnit as an
interface
would be a better choice to provide cleaner approach for customizing the
code. The customization of PUs was added late in the development cycle
of
the CPM, specifically to support single threaded Processing. The initial
design did not allow for customization of PUs. So the current
ProcessingUnit
class should probably be renamed to ProcessingUnitImpl and a new
ProcessingUnit interface should be added. Does not seem like a lot of
work.

Jerry Cwiklik

On Fri, May 8, 2009 at 6:39 PM, <ma...@thomsonreuters.com>
wrote:

> Jerry,
> Let see what I mean:
>
> CPMEngine is references 'ProcessingUnit' which is in turn not the
> interface, but a class
>
> - 1: In order to plug custom 'ProcessingUnit' you have to subclass
from
> 'ProcessingUnit'
> - 2: A good candidate to override is 'processNext', but it this calls:
> private handleEOFToken(), even if one what to duplicate this
>        handleEOFToken calls cpm.processingUnitShutdown, package scope
> function in CPMEngine.
> - 3: There are no good clean point to override without to be exposed
to all
> that processing code.
>
> Ideally it needs well defined points that can be easily overridden
with the
> maximum control over the CAS/CasData flow, that is
>        CAS/CasData,CasData/CAS conversions and calling CasProcessor.
>
>
> -----Original Message-----
> From: Jerry Cwiklik (JIRA) [mailto:uima-dev@incubator.apache.org]
> Sent: Friday, May 08, 2009 7:56 AM
> To: uima-dev@incubator.apache.org
> Subject: [jira] Commented: (UIMA-1338) Custom plugable ProcessingUnit
for
> CPMEngine
>
>
>    [
>
https://issues.apache.org/jira/browse/UIMA-1338?page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707361#
action_12707361]
>
> Jerry Cwiklik commented on UIMA-1338:
> -------------------------------------
>
> Not sure what you mean by
>
> "... boundaries between CPMEngine and ProcessingUnit not clearly
defined."
>
> The custom ProcessingUnit can be plugged in (as you noted) via a
system
> param. The CPMEngine creates as many instances of custom
ProcessingUnits as
> there are processing threads defined in the CPE descriptor:
>
>
> if (System.getProperty("PROCESSING_PIPELINE_IMPL") != null) {
>          String puClass =
System.getProperty("PROCESSING_PIPELINE_IMPL");
>          try {
>            processingUnits[i] = producePU(puClass);
>            processingUnits[i].setInputQueue(workQueue);
>            processingUnits[i].setOutputQueue(outputQueue);
>            processingUnits[i].setCPMEngine(this);
>          } catch (Exception e) {
>
> All PUs share the same Input and Output queues. Think of PUs as Worker
> threads that share the load. CPMEngine creates them and manages
lifecycle of
> PUs.
>
>
> > Custom plugable ProcessingUnit for CPMEngine
> > --------------------------------------------
> >
> >                 Key: UIMA-1338
> >                 URL: https://issues.apache.org/jira/browse/UIMA-1338
> >             Project: UIMA
> >          Issue Type: Improvement
> >          Components: Collection Processing
> >            Reporter: Maksim Likharev
> >            Priority: Minor
> >   Original Estimate: 504h
> >  Remaining Estimate: 504h
> >
> > Kind of intended this way through "PROCESSING_PIPELINE_IMPL" system
> param, but boundaries between CPMEngine and ProcessingUnit not clearly
> defined.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
>