from:"Burn Lewis"


 [ 
https://issues.apache.org/jira/browse/UIMA-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1353:
-

Attachment: (was: UIMA-1353-fixed.patch)

 UIMA-AS JUnit test code suppresses some exceptions so may not report some 
 test failures
 ---

 Key: UIMA-1353
 URL: https://issues.apache.org/jira/browse/UIMA-1353
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS

 Attachments: UIMA-1353_uimaj-as-activemq.patch, 
 UIMA-1353_uimaj-as-jms.patch


 The test support code suppresses the ServiceShutdownException (and others) 
 which can make failing tests appear OK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1355) When one delagate in a parallel step fails, the flow continues without waiting for the last reply


 [ 
https://issues.apache.org/jira/browse/UIMA-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1355:
-

Attachment: UIMA-1355_test_uimaj-as-activemq.patch

Here's a patch that makes testProcessParallelFlowWithDelegateDisable fail as it 
now checks that the other delegate's results do get merged into the CAS.  If 
the final CheckTextAnnotator does not find a SourceDocumentInformatiom 
annotation it fails the test.

 When one delagate in a parallel step fails, the flow continues without 
 waiting for the last reply
 -

 Key: UIMA-1355
 URL: https://issues.apache.org/jira/browse/UIMA-1355
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3S

 Attachments: UIMA-1355_test_uimaj-as-activemq.patch


 When a delegate in a parallel step fails the number of replies received is 
 incremented twice, so the reply from the last delegate is not merged into the 
 CAS.  When it is received it will reenter the flow if the CAS is still 
 active, causing even more trouble.
 I have a test case that demonstrates the problem.
 Also we should make the check for all-replies-received atomic so that only 
 one reply- or error-processing thread will send the CAS on to the next step, 
 or, depending on the error-handling, discard the CAS or terminate the service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information

Exceptions on generated CASes are returned to client without parentage 
information
--

 Key: UIMA-1358
 URL: https://issues.apache.org/jira/browse/UIMA-1358
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Affects Versions: 2.2.2
Reporter: Burn Lewis
 Fix For: 2.3S


The client should be told which of its input CASes might have (indirectly) 
generated this failing CAS.  Also is there any value in sending more than one 
exception if many children fail?  If the aggregate is not a CM then the client 
should just be told that the input CAS failed.
Here is part of a recent email discussion on this problem:


I think I have a somewhat clearer picture of how we might handle errors on 
child CASes.  

First consider Primitive  Aggregate CMs, and then a non-CM aggregate that 
contains a CM. 
I can see 3 different ways an application may wish to handle errors on child 
CASes:

Primitive CM 
Stop generating children/descendants of the input CAS and return an exception 
on the input CAS
Generate an incomplete CAS -- perhaps marked as damaged
(useful when the total count must be preserved and a place-holder provided)
Ignore the error, generate no CAS and carry on to generate the next CAS (if any)

Aggregate CM
Stop generating any more children/descendants from the input CAS and return the 
exception on the input CAS
Allow the CAS to continue in the flow
Quietly drop the CAS, do not return it and do not generate an exception

Simple Aggregate with internal CM
Stop generating any more children/descendants from the input CAS and return the 
exception on the input CAS
Allow the CAS to continue in the flow (it will be dropped at the end of the 
flow)
Quietly drop the CAS as if it reached the end of the flow, and do not generate 
an exception

Currently our aggregate error-handling supports #2, while #3 doesn't depend on 
the framework.  I have added aggregate support for #3 to the 
AdvancedFixedFlowController in the UIMA-AS test suite (as part of Jira 1353) in 
the form of a new AllowDropOnFailure option which specifies the delegates for 
which a failing CAS can be dropped, i.e. skip to the end of the flow with the 
forceCasToBeDropped flag set.  (I used it to test the thresholdWindow error 
handling to verify that an intermittently failing delegate is disabled when N 
of the last M CASes fail.)

But I don't think our docs indicate what should happen in #1 and the current 
implementation handles it differently ... the exception is associated with the 
child CAS without any reference to the input CAS, and the CM continues to 
generate children, so the client can get many exceptions that refer to unknown 
CASes.  The getParentCasReferenceId() method in the UimaASProcessStatus (which 
I could not find in the JavaDocs) can be used to associate a child CAS with the 
input CAS that generated it, but it is always null when an exception is 
returned. 

Consider the information available to the entityProcessComplete callback when 
an input CAS successfully generates 2 children:

returnedCAS getCasReferenceId() getParentCasReferenceId()   
isException()
 
  Child1ID-of-Child1ID-of-Parent
false
  Child2ID-of-Child2ID-of-Parent
false
  ParentID-of-Parentnull
false

If the 2nd child causes an exception then the client might see (Option 
A)

returnedCAS getCasReferenceId() getParentCasReferenceId()   
isException()
 
  Child1ID-of-Child1ID-of-Parent
false
  null  ID-of-Parentnull
true

Or we could put the failing child's ID in the status (Option B)

returnedCAS getCasReferenceId() getParentCasReferenceId()   
isException()
 
  Child1ID-of-Child1ID-of-Parent
false
  null  ID-of-Child2ID-of-Parenttrue

Note that in an Aggregate CM the failing CAS may not have been generated 
directly by the parent, but by any one of its descendants.

I think option A  is cleaner and easier to document ... exception always on 
input CAS.  If the ID of the failing child is useful we could wrap the 
exception in another that said something like Exception inherited from 
generated CAS xyz

Any other options we should consider?
I'll put this in a Jira as that may be the better place to discuss it.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1359) Strange warning message when deploying an Aggregate CM

Strange warning message when deploying an Aggregate CM
--

 Key: UIMA-1359
 URL: https://issues.apache.org/jira/browse/UIMA-1359
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3S


What's the correct syntax when deploying an aggregate CM?

When running testClientWithAggregateMultiplier we get the warning:

  *** WARN: line-number: 36 deployment descriptor for analysisEngine: 
TopLevelTaeQueue is for a top-level CAS Multiplier (or Collection Reader 
wrapped as a CAS Multiplier). 
 However, the lt;casMultipliergt; element is missing. 
 Defaulting to a poolSize of 1, initialFsHeapSize of 2,000,000

but when I add the casMultiplier element it decides to ignore it!

  *** WARNING: line-number: 36 casMultiplier settings for poolSize ( 
poolSize=55) and initialFsHeapSize ( ) 
 will be ignored for the analysisEngine with key= TopLevelTaeQueue 
 because the pool specs are set using the contained delegate cas multiplier 
specification.

The change I made was:
Index: 
uimaj-as-activemq/src/test/resources/deployment/Deploy_AggregateMultiplier.xml
===
--- 
uimaj-as-activemq/src/test/resources/deployment/Deploy_AggregateMultiplier.xml  
(revision 779293)
+++ 
uimaj-as-activemq/src/test/resources/deployment/Deploy_AggregateMultiplier.xml  
(working copy)
@@ -34,6 +34,7 @@
 import 
location=../descriptors/analysis_engine/SimpleTestAggregateCasMultiplier.xml/
   /topDescriptor
   analysisEngine
+   casMultiplier poolSize=55/ 
 delegates
 
   remoteAnalysisEngine key=TestMultiplier



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1353) UIMA-AS JUnit test code suppresses some exceptions so may not report some test failures

2009-05-26 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1353:
-

Attachment: (was: UIMA-1353.patch)

 UIMA-AS JUnit test code suppresses some exceptions so may not report some 
 test failures
 ---

 Key: UIMA-1353
 URL: https://issues.apache.org/jira/browse/UIMA-1353
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS

 Attachments: UIMA-1353-fixed.patch


 The test support code suppresses the ServiceShutdownException (and others) 
 which can make failing tests appear OK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1353) UIMA-AS JUnit test code suppresses some exceptions so may not report some test failures

2009-05-26 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1353:
-

Attachment: UIMA-1353-fixed.patch

Fixed a typo in the patch and made it a DOS file (original had a mixture of DOS 
 Unix lines)
UIMA-1353-fixed.patch

 UIMA-AS JUnit test code suppresses some exceptions so may not report some 
 test failures
 ---

 Key: UIMA-1353
 URL: https://issues.apache.org/jira/browse/UIMA-1353
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS

 Attachments: UIMA-1353-fixed.patch


 The test support code suppresses the ServiceShutdownException (and others) 
 which can make failing tests appear OK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1355) When one delagate in a parallel step fails, the flow continues without waiting for the last reply

2009-05-26 Thread Burn Lewis (JIRA)

When one delagate in a parallel step fails, the flow continues without waiting 
for the last reply
-

 Key: UIMA-1355
 URL: https://issues.apache.org/jira/browse/UIMA-1355
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3S


When a delegate in a parallel step fails the number of replies received is 
incremented twice, so the reply from the last delegate is not merged into the 
CAS.  When it is received it will reenter the flow if the CAS is still active, 
causing even more trouble.
I have a test case that demonstrates the problem.

Also we should make the check for all-replies-received atomic so that only one 
reply- or error-processing thread will send the CAS on to the next step, or, 
depending on the error-handling, discard the CAS or terminate the service.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1353) UIMA-AS JUnit test code suppresses some exceptions so may not report some test failures

2009-05-22 Thread Burn Lewis (JIRA)

UIMA-AS JUnit test code suppresses some exceptions so may not report some test 
failures
---

 Key: UIMA-1353
 URL: https://issues.apache.org/jira/browse/UIMA-1353
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS


The test support code suppresses the ServiceShutdownException (and others) 
which can make failing tests appear OK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1353) UIMA-AS JUnit test code suppresses some exceptions so may not report some test failures

2009-05-22 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1353:
-

Attachment: UIMA-1353.patch

These changes instead only ignore exceptions that occur after the client stops 
the service, assuming that the ServiceShutdownException is to be expected then.
Some tests had to be corrected (by adding to AllowContinueOnFailure) and the 
AdvancedFixedFlowController has a new AllowDropOnFailure option so that child 
CASes with errors can be quietly dropped from the flow and not cause exceptions 
to be returned to the client.
CAS flow tracing has also been added to the flow controller.

One test now fails, testJmsServiceAdapterWithGetmetaTimeout, but I don't think 
it's testing what it should be testing.

 UIMA-AS JUnit test code suppresses some exceptions so may not report some 
 test failures
 ---

 Key: UIMA-1353
 URL: https://issues.apache.org/jira/browse/UIMA-1353
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS

 Attachments: UIMA-1353.patch


 The test support code suppresses the ServiceShutdownException (and others) 
 which can make failing tests appear OK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1339) MESSAGE LOCALIZATION FAILED -- missing key UIMAJMS_send_reply_failed__FINE

2009-05-04 Thread Burn Lewis (JIRA)

MESSAGE LOCALIZATION FAILED -- missing key UIMAJMS_send_reply_failed__FINE
--

 Key: UIMA-1339
 URL: https://issues.apache.org/jira/browse/UIMA-1339
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Affects Versions: 2.3AS
Reporter: Burn Lewis
Priority: Minor


Key in resource bundle is correct (UIMAJMS_send_reply_failed__INFO) ... code is 
wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1339) MESSAGE LOCALIZATION FAILED -- missing key UIMAJMS_send_reply_failed__FINE

2009-05-04 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1339:
-

Attachment: UIMA-1339.patch

A 1-line fix

 MESSAGE LOCALIZATION FAILED -- missing key UIMAJMS_send_reply_failed__FINE
 --

 Key: UIMA-1339
 URL: https://issues.apache.org/jira/browse/UIMA-1339
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Affects Versions: 2.3AS
Reporter: Burn Lewis
Priority: Minor
 Attachments: UIMA-1339.patch


 Key in resource bundle is correct (UIMAJMS_send_reply_failed__INFO) ... code 
 is wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1316) Need to extend FlowControllerContainer to support collectionProcessComplete()

2009-04-06 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696239#action_12696239
 ] 

Burn Lewis commented on UIMA-1316:
--

For the record - the FlowController interface defines a 
collectionProcessComplete method but at present the UIMA framework doesn't call 
it.  
It could be used to report flow statistics, e.g. the number of CAses 
successfully processed by each delegate.

 Need to extend FlowControllerContainer to support collectionProcessComplete()
 -

 Key: UIMA-1316
 URL: https://issues.apache.org/jira/browse/UIMA-1316
 Project: UIMA
  Issue Type: Improvement
  Components: Async Scaleout, Core Java Framework
Reporter: Jerry Cwiklik

 The FlowControllerContainer wrapper around the FlowController object does not 
 expose collectionProcessComplete() method.
 Add a new method and delegate collectionProcessComplete to FlowController 
 instance

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1109) Need ability to quiesce an instance of a service

2009-03-27 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689904#action_12689904
 ] 

Burn Lewis commented on UIMA-1109:
--

Investigation has shown that the java logfile has been closed when the shutdown 
hooks run, but java signal handlers are OK as they are run before it is closed. 
 So we could trigger a graceful shutdown by sending a signal to the JVM running 
deployAsyncService.  On Windows only SIG_INT is supported (Cntl-C) but since 
the process runs in the foreground it could simply wait for a Shutdown 
request to be entered at the terminal.

A more elegant suggestion was to use JMX messaging, identifying a particular 
service by an ID generated at startup.

 Need ability to quiesce an instance of a service
 

 Key: UIMA-1109
 URL: https://issues.apache.org/jira/browse/UIMA-1109
 Project: UIMA
  Issue Type: Improvement
  Components: Async Scaleout
Reporter: Burn Lewis

 We can deploy extra instances of a service seamlessly but also need a 
 mechanism to undeploy without losing any work, i.e. ask an instance to stop 
 processing messages and shutdown when it finishes its current work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1109) Need ability to quiesce an instance of a service

2009-03-24 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12688720#action_12688720
]

Burn Lewis commented on UIMA-1109:
--

I don't think we need to support client-initiated shutdown until we have a way
for clients to deploy remote services. One use case would be when moving a
service to a different machine -- first deploy on the new machine and then
gracefully undeploy on the old machine so that no work is lost. Another would
be when upgrading a service or UIMA-AS.
Currently services are started with deployAsyncService so we need a matching
undeploy that would be run from the same machine that would cause the service
to stop processing input requests and shutdown when the current request has
been completed. For simplicity it should apply to all instances of the service
started by the deploy script, so could use the pid of the JVM and a special
signal, but may not be able to rely on the shutdown hook since the logs may
have been closed ... but perhaps we can add a Java signal handler.

Need ability to quiesce an instance of a service

Key: UIMA-1109
URL: https://issues.apache.org/jira/browse/UIMA-1109
Project: UIMA
Issue Type: Improvement
Components: Async Scaleout
Reporter: Burn Lewis

We can deploy extra instances of a service seamlessly but also need a
mechanism to undeploy without losing any work, i.e. ask an instance to stop
processing messages and shutdown when it finishes its current work.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1296) UIMA AS Service Not Processing Stop Request

[
https://issues.apache.org/jira/browse/UIMA-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677487#action_12677487
]

Burn Lewis commented on UIMA-1296:
--

Shouldn't these requests be sent to the cas-release queue so the correct
instance of the service is stopped?

UIMA AS Service Not Processing Stop Request
---

Key: UIMA-1296
URL: https://issues.apache.org/jira/browse/UIMA-1296
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Jerry Cwiklik
Assignee: Marshall Schor

Remote Uima AS Service is not processing STOP request from a client. These
requests are send by a client to a remote Cas Multiplier to abort generation
of child CAses from a given input CAS. This used to work, but I think got
broken when we've added selectors. We use two selectors on the input queue:
property name=messageSelector value=Command=2000 OR Command=2002/
and
property name=messageSelector value=Command=2001/
The first selector accepts Process and CPC requests which are processed by
one listener and the second selector is for GetMeta requests that are
processed by a separate listener (thread).
We need to process STOP requests by GetMeta listener. dd2Spring need to
change to support addtional request type. Use the following selector on the
GetMeta listener:
property name=messageSelector value=Command=2001 OR Command=2006/

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1297) Uima AS Service Not Handling Send Failures Correctly


[ 
https://issues.apache.org/jira/browse/UIMA-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677488#action_12677488
 ] 

Burn Lewis commented on UIMA-1297:
--

We've discussed an optimization that would immediately execute the error 
handling as if a timeout had occurred (since that's what would happen if the 
request was lost later in the network) but decided to postpone that for now 
until we understand its impact on the new single-timer-per-delegate 
implementation.

 Uima AS Service Not Handling Send Failures Correctly
 

 Key: UIMA-1297
 URL: https://issues.apache.org/jira/browse/UIMA-1297
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Jerry Cwiklik
Assignee: Jerry Cwiklik

 When a send requst fails due to a lost broker connection, the uima AS 
 aggregate removes the CAS from the outstanding list. Subsequently, when a 
 timer pops the Timeout Exception is reported against the wrong CAS.
 Fix the code so that the CAS remains in the outstanding list until the timer 
 pops.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1297) Uima AS Service Not Handling Send Failures Correctly


[ 
https://issues.apache.org/jira/browse/UIMA-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677496#action_12677496
 ] 

Burn Lewis commented on UIMA-1297:
--

In one of our logs I noticed that even though the a send to a remote service 
failed, later sends appeared to work and we continued to use the same temp 
reply queue, so presumably its listener didn't lose connection to the broker!?

 Uima AS Service Not Handling Send Failures Correctly
 

 Key: UIMA-1297
 URL: https://issues.apache.org/jira/browse/UIMA-1297
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Jerry Cwiklik
Assignee: Jerry Cwiklik

 When a send requst fails due to a lost broker connection, the uima AS 
 aggregate removes the CAS from the outstanding list. Subsequently, when a 
 timer pops the Timeout Exception is reported against the wrong CAS.
 Fix the code so that the CAS remains in the outstanding list until the timer 
 pops.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1298) A shared remote CM hangs when one of its clients runs out of memory

A shared remote CM hangs when one of its clients runs out of memory 


 Key: UIMA-1298
 URL: https://issues.apache.org/jira/browse/UIMA-1298
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3S


Twice I observed that when one client aggregate of a shared remote CM crashed 
with an out-of-memory exception the service stopped responding to the other 
client's requests.  No errors found in the service log.  The client was not 
using the service at the time of the crash.  Requests stacked up on the input 
queue ... almost as if the service was blocked on an empty pool, or ...?  
Killing a client (cntl-C) did not cause the hang.  Weird!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1245) Processing order of parent CAS different on UIMA and UIMA AS

2009-02-25 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676750#action_12676750
]

Burn Lewis commented on UIMA-1245:
--

My suggestion that we should attempt to emulate core UIMA's single-threaded
handling of parents was clearly over-design when all that appears to be
needed is a way to optionally ensure that parents follow children in the flow.

I assume that in 3) you mean that the parameter is part of the CasMultiplier
specification in the deployment descriptor for the aggregate, i.e. applies per
CasMultiplier and not to all CasMulti[pliers in the aggregate. Since the
default (I hope) will be to let the parent continue in the flow as soon as its
last child has entered the flow, perhaps the parameter for this new feature
could indicate that the parent's processing will be suspended until all its
child CASes have completed their processing in the aggregate. Since the docs
use the terms input/output instead of parent/child perhaps...

casMultiplier poolSize=6 suspendInputCas=true/
or
casMultiplier poolSize=6 processInputCasAfterOutputs=true/

+1 for the simpler per-aggregate design

Processing order of parent CAS different on UIMA and UIMA AS

Key: UIMA-1245
URL: https://issues.apache.org/jira/browse/UIMA-1245
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Eddie Epstein

Arron Kaplan raised the question of when parent CASes are processed relative
to their children. See http://markmail.org/message/5cop7iv2nshouhgs As of
now, the processing order for a multi-threaded UIMA AS aggregate is different
than that for a single-threaded UIMA aggregate.
A discussion with Burn, Adam, Jerry, Marshall and myself concluded that the
default processing order for UIMA AS should be changed to be the same as in
UIMA, in order to have the same application behavior for both. This will be
done by suspending flow of a parent CAS after it is returned from a
CasMultiplier delegate until all its children CASes have finished processing.
However, there also needs to be a UIMA AS deployment option for CasMultiplier
delegates that allows the parent CAS to resume processing immediately after
being returned from the CM. This option is needed to enable parallel
processing.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1245) Processing order of parent CAS different on UIMA and UIMA AS

2009-02-24 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676308#action_12676308
]

Burn Lewis commented on UIMA-1245:
--

To summarize my understanding of recent discussions ...

First I'd like to suggest that the default should not change. Processing the
parent last does not guarantee that UIMA-AS will act like core UIMA ... in
addition the size of all downstream pools must be set to 1 to ensure that each
child is processed sequentially. We should document the settings needed for
UIMA-like processing but I think the default should be UIMA-AS style
processing, i.e. processParentLast=false.

With the current design parents are held in the final step of an aggregate
until all children have completed processing in that aggregate. This ensures
that any child errors can be reported on the input CAS, and that aggregate CMs
satisfy the CM contract of not processing the parent until all children have
been returned. If this aggregate is nested in another, the same conditions
hold at the final step of the outer aggregate.

But with this new processParentLast=true option the parent must be held after
the CM until all of its children have completed processing in all aggregates,
i.e. have been returned to their pool. Unlike the previous case we must track
the number of children active in any of the nested aggregates.

Processing order of parent CAS different on UIMA and UIMA AS

Key: UIMA-1245
URL: https://issues.apache.org/jira/browse/UIMA-1245
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Eddie Epstein

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1293) Remote CasMultipliers that don't always generate CASes not handled correctly

2009-02-23 Thread Burn Lewis (JIRA)

Remote CasMultipliers that don't always generate CASes not handled correctly


 Key: UIMA-1293
 URL: https://issues.apache.org/jira/browse/UIMA-1293
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3


If a remote CM generates 1 CAS for every N input, some of the childless parents 
do not continue in the flow. Since the default FC uses dropIfNewCasProduced 
all CASes should continue in the flow except for every N-th one being replaced 
by its child.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1293) Replies from remote CasMultipliers that don't always generate CASes are not handled correctly

2009-02-23 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1293:
-

Summary: Replies from remote CasMultipliers that don't always generate 
CASes are not handled correctly  (was: Remote CasMultipliers that don't always 
generate CASes not handled correctly)

 Replies from remote CasMultipliers that don't always generate CASes are not 
 handled correctly
 -

 Key: UIMA-1293
 URL: https://issues.apache.org/jira/browse/UIMA-1293
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3


 If a remote CM generates 1 CAS for every N input, some of the childless 
 parents do not continue in the flow. Since the default FC uses 
 dropIfNewCasProduced all CASes should continue in the flow except for every 
 N-th one being replaced by its child.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (UIMA-1071) http connector fails with some Java implementations

2009-02-19 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis reopened UIMA-1071:
--


The old xstream-1.1.2.jar is still specified in setUimaClassPath so http 
services still fail


 http connector fails with some Java implementations
 ---

 Key: UIMA-1071
 URL: https://issues.apache.org/jira/browse/UIMA-1071
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Eddie Epstein
Assignee: Eddie Epstein
 Fix For: 2.3S


 Using the http connector with AMQ 4.1.1 on some 64-bit JRE's results in an 
 exception:
 Caused by: java.lang.RuntimeException: Could not access 
 java.util.EnumSet.elementType field
 at com.thoughtworks.xstream.core.util.Fields.find(Fields.java:18)
 at 
 com.thoughtworks.xstream.converters.enums.EnumSetConverter.init(EnumSetConverter.java:31)
 The problem is identified here: http://jira.codehaus.org/browse/XSTR-379
 and the fix is to use xstream-1.2.2.jar instead of the 1.1.2 version.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-857) Change startup of framework to support versioned Jars and simplified classpath

2009-02-17 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674349#action_12674349
 ] 

Burn Lewis commented on UIMA-857:
-

Yes, with something like UIMA_JARPATH we could add the ActiveMQ libraries and 
the UIMA library to any user libraries of jar files.  
Presumably we'd choose a predictable order, e.g. alphabetical, for the jars in 
a directory.

 Change startup of framework to support versioned Jars and simplified classpath
 --

 Key: UIMA-857
 URL: https://issues.apache.org/jira/browse/UIMA-857
 Project: UIMA
  Issue Type: Improvement
  Components: Build, Packaging and Test
Reporter: Marshall Schor
Priority: Minor

 Our approach to the framework classpath is to (a) strip version info from our 
 Jar names, and (b) have a setUimaClassPath script that adds lots of these 
 (unversioned) jars to the classpath.
 Other systems use a different approach - usually putting all the jars that 
 should be in the classpath into a directory, and then having a small wrapper 
 jar (with an unversioned name) that adds all the jars it finds in this dir to 
 the classpath.  (See for instance, ActiveMQ startup, or the way things like 
 Tomcat work).Change UIMA to use this approach.   (Not for 2.2.2, but for 
 following release, perhaps).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1289) If an aggregate uses the unsupported include instead of import a very very very obscure error message results

2009-02-05 Thread Burn Lewis (JIRA)

If an aggregate uses the unsupported include instead of import a very very 
very obscure error message results
-

 Key: UIMA-1289
 URL: https://issues.apache.org/jira/browse/UIMA-1289
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Priority: Minor


In converting a CPE descriptor to an aggregate descriptor I forgot to change 
one include ... to import 
The docs indicate that include is not supported but the CDE error message was:

ResourceInitializationException: The CasCreationUtils.createCas method was 
passed a collection containing an object of class 
org.apache.uima.collection.impl.metadata.cpe.CpeIncludeImpl, which is not 
supported.

Not very helpful!  

The cvd reported a stack trace but still no clue as to what part of what file 
was in error:

org.apache.uima.tools.cvd.MainFrame.handleException(575): SEVERE: 
org.apache.uima.collection.impl.metadata.cpe.CpeIncludeImpl incompatible with 
org.apache.uima.resource.ResourceSpecifier
java.lang.ClassCastException: 
org.apache.uima.collection.impl.metadata.cpe.CpeIncludeImpl incompatible with 
org.apache.uima.resource.ResourceSpecifier
at 
org.apache.uima.analysis_engine.impl.AnalysisEngineDescription_impl.getComponentSpecifier(AnalysisEngineDescription_impl.java:439)
at 
org.apache.uima.analysis_engine.impl.AnalysisEngineDescription_impl.checkForInvalidParameterOverrides(AnalysisEngineDescription_impl.java:380)
at 
org.apache.uima.resource.impl.ResourceCreationSpecifier_impl.validateConfigurationParameters(ResourceCreationSpecifier_impl.java:246)
at 
org.apache.uima.resource.impl.ResourceCreationSpecifier_impl.validate(ResourceCreationSpecifier_impl.java:219)
at 
org.apache.uima.analysis_engine.impl.AnalysisEngineDescription_impl.validate(AnalysisEngineDescription_impl.java:304)
at 
org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.initialize(AggregateAnalysisEngine_impl.java:163)
at 
org.apache.uima.impl.AnalysisEngineFactory_impl.produceResource(AnalysisEngineFactory_impl.java:94)
at 
org.apache.uima.impl.CompositeResourceFactory_impl.produceResource(CompositeResourceFactory_impl.java:62)
at org.apache.uima.UIMAFramework.produceResource(UIMAFramework.java:258)
at org.apache.uima.UIMAFramework.produceResource(UIMAFramework.java:303)
at 
org.apache.uima.UIMAFramework.produceAnalysisEngine(UIMAFramework.java:383)
at org.apache.uima.tools.cvd.MainFrame.setupAE(MainFrame.java:1529)
at 
org.apache.uima.tools.cvd.MainFrame.loadAEDescriptor(MainFrame.java:524)
at 
org.apache.uima.tools.cvd.control.AnnotatorOpenEventHandler.actionPerformed(AnnotatorOpenEventHandler.java:52)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2006)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2329)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:398)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:253)
at javax.swing.AbstractButton.doClick(AbstractButton.java:368)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1231)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1272)
at java.awt.Component.processMouseEvent(Component.java:6052)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3276)
at java.awt.Component.processEvent(Component.java:5817)
at java.awt.Container.processEvent(Container.java:2069)
at java.awt.Component.dispatchEventImpl(Component.java:4424)
at java.awt.Container.dispatchEventImpl(Container.java:2127)
at java.awt.Component.dispatchEvent(Component.java:4254)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4333)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3997)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3927)
at java.awt.Container.dispatchEventImpl(Container.java:2113)
at java.awt.Window.dispatchEventImpl(Window.java:2451)
at java.awt.Component.dispatchEvent(Component.java:4254)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:610)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:284)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:194)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:179)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:171

[jira] Created: (UIMA-1280) Missing message key in CPM at FINEST logging

2009-01-27 Thread Burn Lewis (JIRA)

Missing message key in CPM at FINEST logging


 Key: UIMA-1280
 URL: https://issues.apache.org/jira/browse/UIMA-1280
 Project: UIMA
  Issue Type: Bug
  Components: Collection Processing
Affects Versions: 2.2.2
Reporter: Burn Lewis
Priority: Minor


The message key UIMA_CPM_pipeline_exception__FINEST is used in 
org.apache.uima.collection.impl.cpm.engine.ProcessingUnit but is not in the 
properties file org.apache.uima.collection.impl.cpm.cpm_messages

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1270) runRemoteAsyncAE uses binary serialization which is not supported for native CPP services

2009-01-22 Thread Burn Lewis (JIRA)

runRemoteAsyncAE uses binary serialization which is not supported for native 
CPP services
-

 Key: UIMA-1270
 URL: https://issues.apache.org/jira/browse/UIMA-1270
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3AS


Default serialization should be xmi with binary an option

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1270) runRemoteAsyncAE uses binary serialization which is not supported for native CPP services

2009-01-22 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1270:
-

Attachment: UIMA-1270.patch

Added -b option for binary serialization.  Created a common application 
context Map ... should all or some of the args apply to the deployed services??

Also fixed a log message that printed deserialization time in microsecs instead 
of millisecs

 runRemoteAsyncAE uses binary serialization which is not supported for native 
 CPP services
 -

 Key: UIMA-1270
 URL: https://issues.apache.org/jira/browse/UIMA-1270
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3AS

 Attachments: UIMA-1270.patch


 Default serialization should be xmi with binary an option

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1269) NPE when using a C++ service deployed via JNI

2009-01-21 Thread Burn Lewis (JIRA)

NPE when using a C++ service deployed via JNI
-

 Key: UIMA-1269
 URL: https://issues.apache.org/jira/browse/UIMA-1269
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Affects Versions: 2.2.2
Reporter: Burn Lewis


C++ services don't support delta CAS so the JNI wrapper clears the Marker 
before uploading the C++ CAS but then the service crashes when trying to return 
a delta CAS to its caller.  May also have a problem in an aggregate if one of 
its services does not support delta CAS ... need to invalidate the input Marker 
and make the aggregate return a full CAS.  Should also create a fresh Marker 
for following delegates so they can return delta CASes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1251) If one delegate in an aggregate uses a JMS service descriptor and another fails to initialize, the JVM fails to terminate

2008-12-17 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657416#action_12657416
]

Burn Lewis commented on UIMA-1251:
--

The When called section could be updated, but the Requirements say destroy
should release resources to get ready for another initialize which implies that
it should undo the effect of any previous initialize, even if partial ... but
it wouldn't hurt to clarify that. Meanwhile we should try to ensure the
framework classes follow a similar contract where appropriate, and Marshall has
found a problem with my patch as it exposes a bug in the
FlowControllerContainer's destroy method after partial initialization.

If one delegate in an aggregate uses a JMS service descriptor and another
fails to initialize, the JVM fails to terminate
-

Key: UIMA-1251
URL: https://issues.apache.org/jira/browse/UIMA-1251
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Assignee: Marshall Schor
Attachments: UIMA-1251.patch

When initialization of an aggregate fails we need to give the successful
delegates the opportunity to release their resources. Critical for JMS
service adapters as they create a thread that waits on replies from the
remote service. Reported as a runAE hang by Jerry Quinn.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1250) Some initialization messages may not appear as the Logger object changes during initialization

2008-12-16 Thread Burn Lewis (JIRA)

Some initialization messages may not appear as the Logger object changes during 
initialization
--

 Key: UIMA-1250
 URL: https://issues.apache.org/jira/browse/UIMA-1250
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Priority: Minor


In the initialize method in AggregateAnalysisEngine_impl the logger object 
returned by the local getLogger() method changes ... for the init_begin msg it 
is correct, but after initASB has been called when the init_successful msg is 
logged the logger object is the one for the ASB_impl class.  All 3 
implementations of AnalysisEngine use the getLogger() method in 
Resource_ImplBase which gets it from its local UimaContext ... but this is 
changed during initialization.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1251) If one delegate in an aggregate uses a JMS service descriptor and another fails to initialize, the JVM fails to terminate

2008-12-16 Thread Burn Lewis (JIRA)

If one delegate in an aggregate uses a JMS service descriptor and another fails 
to initialize, the JVM fails to terminate
-

 Key: UIMA-1251
 URL: https://issues.apache.org/jira/browse/UIMA-1251
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis


When initialization of an aggregate fails we need to give the successful 
delegates the opportunity to release their resources.  Critical for JMS service 
adapters as they create a thread that waits on replies from the remote service. 
 Reported as a runAE hang by Jerry Quinn.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1251) If one delegate in an aggregate uses a JMS service descriptor and another fails to initialize, the JVM fails to terminate

2008-12-16 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1251:
-

Attachment: UIMA-1251.patch

This patch catches the exception, calls destroy on the aggregate, and rethrows 
the exception.

 If one delegate in an aggregate uses a JMS service descriptor and another 
 fails to initialize, the JVM fails to terminate
 -

 Key: UIMA-1251
 URL: https://issues.apache.org/jira/browse/UIMA-1251
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
 Attachments: UIMA-1251.patch


 When initialization of an aggregate fails we need to give the successful 
 delegates the opportunity to release their resources.  Critical for JMS 
 service adapters as they create a thread that waits on replies from the 
 remote service.  Reported as a runAE hang by Jerry Quinn.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1245) Processing order of parent CAS different on UIMA and UIMA AS

2008-12-12 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656131#action_12656131
]

Burn Lewis commented on UIMA-1245:
--

Marshall's generalization to apply process-parent-last to any delegate, not
just the first after a CM, would probably be only useful with a custom Flow
Controller, so perhaps it should be controlled via the FC. If we added a
wait-for-children flag to each Step object then when set true the framework
could suspend the flow of any CAS with active children. When all children are
released the controller would process the parent's flow. We're currently doing
this just for the FinalStep but generalizing to any Step would be easy. (The
flag would always be set for FinalStep as all children must complete without
errors before the parent is released.)
We could add a new wait choice to the ActionAfterCasMultiplier configuration
parameter in the Fixed Advanced FCs

Processing order of parent CAS different on UIMA and UIMA AS

Key: UIMA-1245
URL: https://issues.apache.org/jira/browse/UIMA-1245
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Eddie Epstein

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1245) Processing order of parent CAS different on UIMA and UIMA AS

2008-12-09 Thread Burn Lewis (JIRA)

[
https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654817#action_12654817
]

Burn Lewis commented on UIMA-1245:
--

I think we could get the same behaviour as single-threaded UIMA if in addition
to delaying the processing of the parent we set the size of all CAS pools to 1.
This would ensure that only one child at a time would be active and the next
would not start until the previous had been returned to the pool. If the CM is
remote then when the child CAS is returned to the AGGR ~outer~ pool it signals
back to AGGR ~inner~ that a CAS has been released which would then release its
copy of the child and so allow the CM in AGGR ~inner~ to generate the next
child. Then when all children have been released the held-up parent CAS would
be allowed to continue in the flow.

Also, as we discussed, this process-parent-last option would be more useful
than for just emulating single-threaded operation. An aggregate could use a CM
to split its work into many parallel pieces, and then use a final CM to combine
the results of its children and merge them into the parent before it exits the
aggregate. The new option would ensure that the parent reaches the final CM
only after all its children. This would let the aggregate process its children
asynchronously but appear to its caller as a non-CM simple aggregate.

I assume this would be a per-CM option, not application wide where should
we specify it and how? Should we make this new behaviour the default? Should
the default be true or false? Perhaps in the deployment descriptor:

{{casMultiplier poolSize=1 processParentLast=true}}
or
{{casMultiplier poolSize=1 processParentEarly=false}}
or

Processing order of parent CAS different on UIMA and UIMA AS

Key: UIMA-1245
URL: https://issues.apache.org/jira/browse/UIMA-1245
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Eddie Epstein

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (UIMA-1209) Old 2.2.2 services cannot be used in parallel

2008-11-26 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis closed UIMA-1209.



Tested against IOD 2.2.2 services

 Old 2.2.2 services cannot be used in parallel
 -

 Key: UIMA-1209
 URL: https://issues.apache.org/jira/browse/UIMA-1209
 Project: UIMA
  Issue Type: Bug
Reporter: Burn Lewis
Assignee: Burn Lewis
Priority: Minor
 Attachments: UIMA-1209-3.patch


 New delta CAS support insists that remote services run in parallel must use 
 delta CAS, but we should also support services still running 2.2.2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1171) Initialization hangs if an Exception is thrown when initializing the flow controller AND delegates are offline

2008-11-26 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651137#action_12651137
 ] 

Burn Lewis commented on UIMA-1171:
--

This now looks to have been fixed ... not sure how or when.

 Initialization hangs if an Exception is thrown when initializing the flow 
 controller AND delegates are offline
 --

 Key: UIMA-1171
 URL: https://issues.apache.org/jira/browse/UIMA-1171
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Affects Versions: 2.2.2
Reporter: Burn Lewis
Assignee: Burn Lewis
 Fix For: 2.3AS

 Attachments: UIMA-1171-test.patch, UIMA-1171-test2.patch


 If the framework has some delegates to disable (i.e. failed getMeta) it calls 
 the flow controller's initialize method on a different path and the 
 ResourceInitializationException is caught and rethrown as AsynchAEException 
 ... this causes the deployment to hang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1237) Fix Cas Not Found In CasManager Cache Error in the Parallel Step

2008-11-26 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651151#action_12651151
 ] 

Burn Lewis commented on UIMA-1237:
--

Another way to do this that I think will be safe is to make the synchronized 
incrementHowManyDelegatesResponded() return a boolean when all have responded 
... then only one thread will actually get the all-done flag.

 Fix Cas Not Found In CasManager Cache Error in the Parallel Step
 --

 Key: UIMA-1237
 URL: https://issues.apache.org/jira/browse/UIMA-1237
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Jerry Cwiklik
 Attachments: uimaj-as-core-UIMA-1237-patch-02.txt, 
 uimaj-as-core-UIMA-1237-patch.txt


 There is an exception when processing a secondary reply from a delegate in a 
 parallel step. The exception indicates that the CAS id received in a reply 
 message from one of the delegates in the parallel step does not exist in the 
 cache. The exception happens in the testcase that tests disable of one of the 
 delegates in the parallel step. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1206) Add the capability to browse subdirectories to org.apache.uima.examples.cpe.FileSystemCollectionReader

2008-11-25 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650691#action_12650691
 ] 

Burn Lewis commented on UIMA-1206:
--

My windows patch program worked only after I made it a pure DOS file ... 
currently only some lines end with cntl-M

 Add the capability to browse subdirectories to 
 org.apache.uima.examples.cpe.FileSystemCollectionReader
 --

 Key: UIMA-1206
 URL: https://issues.apache.org/jira/browse/UIMA-1206
 Project: UIMA
  Issue Type: Improvement
  Components: Examples
Affects Versions: 2.2.2
 Environment: Operating System : GNU/Linux Ubuntu Hardy Heron
 Java : java version 1.6.0_06
 Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
 Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
 UIMA svn revision : 704699
Reporter: Fabien POULARD
Priority: Minor
 Attachments: browse-subdirectories.patch


 Make the component org.apache.uima.examples.cpe.FileSystemCollectionReader 
 able to browse sub-directories of the InputDirectory through an option.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1210) XmiCollectionReader fails when it encounters unknown types

2008-11-25 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650712#action_12650712
 ] 

Burn Lewis commented on UIMA-1210:
--

Looks like the patch was computed against the wrong file ... 
XmiWriterCasConsumer

 XmiCollectionReader fails when it encounters unknown types
 --

 Key: UIMA-1210
 URL: https://issues.apache.org/jira/browse/UIMA-1210
 Project: UIMA
  Issue Type: New Feature
  Components: Examples
Affects Versions: 2.2.2
 Environment: GNU/Linux Ubuntu Hardy Heron 8.04
 java version 1.6.0_07
 Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
 Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
Reporter: Fabien POULARD
Priority: Trivial
 Attachments: xmicollectionreader-desc.patch, 
 xmicollectionreader-java.patch


 When XmiCollectionReader is used as CollectionReader and it encounters types 
 that are not present in the TypeSystems provided with the analysis engines, 
 then it fails. There should be an option to silently ignore those errors and 
 still load the CAS.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1227) Help users debug binary CAS serialization problems

2008-11-20 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649526#action_12649526
 ] 

Burn Lewis commented on UIMA-1227:
--

If we construct the getMeta reply on each service by serializing its binary 
typesystem, then comparing the string form of the typesystem should be 
equivalent to comparing the binary form.  And require no changes to the message 
formats.


 Help users debug binary CAS serialization problems
 --

 Key: UIMA-1227
 URL: https://issues.apache.org/jira/browse/UIMA-1227
 Project: UIMA
  Issue Type: Improvement
  Components: Async Scaleout
Reporter: Eddie Epstein

 In order to use binary CAS serialization for remote services, both client and 
 service must have identical type systems. If not the same, binary 
 deserialization is likely to throw exceptions. The service request handler 
 should catch these exceptions when using binary deserialization and add 
 message suggesting a likely cause of the problem: unequal type systems.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (UIMA-1228) Merging results from a parallel step fails when a feature is an array of pre-existing annotations

2008-11-12 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis closed UIMA-1228.



Tests OK.

 Merging results from a parallel step fails when a feature is an array of 
 pre-existing annotations
 -

 Key: UIMA-1228
 URL: https://issues.apache.org/jira/browse/UIMA-1228
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Reporter: Burn Lewis
Assignee: Burn Lewis
 Fix For: 2.3

 Attachments: UIMA-1228-test.patch, UIMA-1228.patch


 Found when doing 2.2.2-style merging (non deltaCas) of new arrays referencing 
 preexisting annotations, but also fails with delta CASes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.

2008-11-11 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646550#action_12646550
 ] 

Burn Lewis commented on UIMA-1119:
--

Our documentation refers to the old XCAS format and the new XMI format for 
representing CASes in XML.  I think it is acceptable to use the terms XMI and 
XCAS when referring to XML representations of CASes.  Also we provide a class 
org.apache.uima.util.XmlCasDeserializer that will read either ... its Javadocs 
say:

Deserializes a CAS from a standoff-XML format. This class can read the XMI 
format introduced in UIMA v1.4 as well as the XCAS format from previous 
versions. 

Eclipse cannot find any callers of any of the setDocumentLocator methods ... 
perhaps we should be creating a Locator and setting it as it would be somewhat 
helpful to know where the error is.

Can we not simply change the error messages to refer to XML parsing? It'll be 
pretty obvious which format is being used.

Yes, and we'd also need a comment about XMI in XCASParsingException.java
Or change to xmlcas.properties  XmlParsingException.java

 The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, 
 but doesn't report the offending element.
 ---

 Key: UIMA-1119
 URL: https://issues.apache.org/jira/browse/UIMA-1119
 Project: UIMA
  Issue Type: Improvement
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Assignee: Marshall Schor
Priority: Minor
 Attachments: UIMA-1119-3.patch


 Obviously it's dangerous to edit XCASes but it is often the quickest way to 
 produce a variety of test cases for an annotator.  By changing a few lines we 
 can report the invalid id.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1228) Merging results from a parallel step fails when a feature is an array of pre-existing annotations

2008-11-11 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1228:
-

Attachment: UIMA-1228.patch

UIMA-1228.patch fixes the problem ... a simple 1-line change.

 Merging results from a parallel step fails when a feature is an array of 
 pre-existing annotations
 -

 Key: UIMA-1228
 URL: https://issues.apache.org/jira/browse/UIMA-1228
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3AS

 Attachments: UIMA-1228-test.patch, UIMA-1228.patch


 Found when doing 2.2.2-style merging (non deltaCas) of new arrays referencing 
 preexisting annotations, but also fails with delta CASes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.

2008-11-11 Thread Burn Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/UIMA-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646556#action_12646556
 ] 

Burn Lewis commented on UIMA-1119:
--

More on the naming issue ... on the IOD project we've been using the term XCAS 
for any XML CAS ... we don't care which format as the collection reader accepts 
either.  Admittedly confusing to refer to an XCAS-formatted XCAS but we rarely 
have to.

 The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, 
 but doesn't report the offending element.
 ---

 Key: UIMA-1119
 URL: https://issues.apache.org/jira/browse/UIMA-1119
 Project: UIMA
  Issue Type: Improvement
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Assignee: Marshall Schor
Priority: Minor
 Attachments: UIMA-1119-3.patch


 Obviously it's dangerous to edit XCASes but it is often the quickest way to 
 produce a variety of test cases for an annotator.  By changing a few lines we 
 can report the invalid id.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1228) Merging results from a parallel step fails when a feature is an array of pre-existing annotations

2008-11-10 Thread Burn Lewis (JIRA)

Merging results from a parallel step fails when a feature is an array of 
pre-existing annotations
-

 Key: UIMA-1228
 URL: https://issues.apache.org/jira/browse/UIMA-1228
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3AS


Found when doing 2.2.2-style merging (non deltaCas) of new arrays referencing 
preexisting annotations, but also fails with delta CASes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1228) Merging results from a parallel step fails when a feature is an array of pre-existing annotations

2008-11-10 Thread Burn Lewis (JIRA)


 [ 
https://issues.apache.org/jira/browse/UIMA-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1228:
-

Attachment: UIMA-1228-test.patch

Here's a patch for the JUnit tests that exposes the problem.  I also combined 
the merging tests so that testMerging  testDeltaCasMerging share code ... 
could add more sharing.

 Merging results from a parallel step fails when a feature is an array of 
 pre-existing annotations
 -

 Key: UIMA-1228
 URL: https://issues.apache.org/jira/browse/UIMA-1228
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Fix For: 2.3AS

 Attachments: UIMA-1228-test.patch


 Found when doing 2.2.2-style merging (non deltaCas) of new arrays referencing 
 preexisting annotations, but also fails with delta CASes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (UIMA-1224) Exceptions received from a delegate don't identify their origin

Exceptions received from a delegate don't identify their origin
---

 Key: UIMA-1224
 URL: https://issues.apache.org/jira/browse/UIMA-1224
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
Priority: Minor
 Fix For: 2.3AS


Here's an exception in the client log that came from a remote delegate ... the 
only way I know that it is not a local exception is that I see a foreign class 
org.gale.columbia.TopicSummarizer deep in the stack trace.  We should add a 
line indicating which delegate returned the exception.  Perhaps we should also 
suppress the first trace as it doesn't carry any useful information about the 
error.


11/4/08 5:49:27 PM - 4: 
org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError: WARNING: 
{0}
org.apache.uima.aae.error.UimaEEServiceException: 
org.apache.uima.analysis_engine.AnalysisEngineProcessException
at 
org.apache.uima.adapter.jms.activemq.JmsOutputChannel.sendReply(JmsOutputChannel.java:761)
at 
org.apache.uima.aae.error.handler.ProcessCasErrorHandler.sendExceptionToClient(ProcessCasErrorHandler.java:105)
at 
org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError(ProcessCasErrorHandler.java:483)
at 
org.apache.uima.aae.error.ErrorHandlerChain.handle(ErrorHandlerChain.java:64)
at 
org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.process(PrimitiveAnalysisEngineController_impl.java:479)
at 
org.apache.uima.aae.handler.HandlerBase.invokeProcess(HandlerBase.java:125)
at 
org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handleProcessRequestWithXMI(ProcessRequestHandler_impl.java:316)
at 
org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handle(ProcessRequestHandler_impl.java:695)
at 
org.apache.uima.aae.handler.input.MetadataRequestHandler_impl.handle(MetadataRequestHandler_impl.java:82)
at 
org.apache.uima.adapter.jms.activemq.JmsInputChannel.onMessage(JmsInputChannel.java:549)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:485)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:442)
at 
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:414)
at 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:309)
at 
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:254)
at 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:871)
at 
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:818)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException
at org.gale.columbia.TopicSummarizer.process(TopicSummarizer.java:352)
at 
org.apache.uima.analysis_component.CasAnnotator_ImplBase.process(CasAnnotator_ImplBase.java:56)
at 
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:375)
at 
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:297)
at 
org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.process(PrimitiveAnalysisEngineController_impl.java:338)
... 15 more
Caused by: java.io.FileNotFoundException: 
work/9.2.176.254_pvirga_20081104/BlankStory/webar20081104aljazeerareposrev_122www.aljazeera.netnewsTemplatesPostingsHumanRightsDetailedPage.aspx?FRAMELESS=falseNRNODEGUID={30F2C898-3504-4FBC-A7BC-4A66B26538BB}NRORIGINALURL=%2FNR%2Fexeres%2F30F2C898-3504-4FBC-A7BC-4A66B26538BB.htmNRCACHEHINT=Guest.txt
 (File name too long)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at java.io.FileWriter.init(FileWriter.java:46)
at org.gale.columbia.TopicSummarizer.process(TopicSummarizer.java:255)
... 19 more


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.


[ 
https://issues.apache.org/jira/browse/UIMA-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645497#action_12645497
 ] 

Burn Lewis commented on UIMA-1119:
--

6 of the original 12 types of XCASParsingException are thrown from this code, 
so I was simply propagating the confusion!  The stack trace will show which 
format is in use so perhaps we could change the messages to start with:

Error parsing XML from source {0} at line {1}, column {2}: 

Also do we ever have the location information?  I don't see any code setting 
the Locator so these 3 values are always unknown

 The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, 
 but doesn't report the offending element.
 ---

 Key: UIMA-1119
 URL: https://issues.apache.org/jira/browse/UIMA-1119
 Project: UIMA
  Issue Type: Improvement
  Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Burn Lewis
Assignee: Marshall Schor
Priority: Minor
 Attachments: UIMA-1119-3.patch


 Obviously it's dangerous to edit XCASes but it is often the quickest way to 
 produce a variety of test cases for an annotator.  By changing a few lines we 
 can report the invalid id.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1166) Getmeta replies from some remote delegates are ignored, causing a timeout


 [ 
https://issues.apache.org/jira/browse/UIMA-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1166:
-

Attachment: UIMA-1166-2.patch

This patch replaces the first ... fixes one more case and is against latest 
code.

 Getmeta replies from some remote delegates are ignored, causing a timeout
 -

 Key: UIMA-1166
 URL: https://issues.apache.org/jira/browse/UIMA-1166
 Project: UIMA
  Issue Type: Bug
  Components: Async Scaleout
Reporter: Burn Lewis
 Attachments: UIMA-1166-2.patch, UIMA-1166-patch.txt


 The reply is falsely discarded:
 9/4/08 3:15:05 PM - 22: 
 org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.mergeTypeSystem:
  INFO: Controller: IODBurnTest Received Metadata From an Invalid (Possibly 
 Disabled) Delegate: TopicLabellerAnnotatorQueue
 The recent change to support duplicate queue names on different brokers 
 checks the broker name returned in the reply against the broker the request 
 was sent to.  But the service returns the name it uses for the broker, e.g. 
 tcp://localhost:61616, and not the external name of the broker.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1209) Old 2.2.2 services cannot be used in parallel


 [ 
https://issues.apache.org/jira/browse/UIMA-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Burn Lewis updated UIMA-1209:
-

Attachment: UIMA-1209-2.patch

This patch replaces the first ... applied against latest code.
Does old-style merging for a parallel step if the service doesn't return a 
delta CAS (2.2.2)

 Old 2.2.2 services cannot be used in parallel
 -

 Key: UIMA-1209
 URL: https://issues.apache.org/jira/browse/UIMA-1209
 Project: UIMA
  Issue Type: Bug
Reporter: Burn Lewis
Priority: Minor
 Attachments: UIMA-1209-2.patch


 New delta CAS support insists that remote services run in parallel must use 
 delta CAS, but we should also support services still running 2.2.2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (UIMA-1209) Old 2.2.2 services cannot be used in parallel