Re: [jira] Commented: (UIMA-911) CasMultiplier's hasNext() called twice without an intervening next()
Adam Lally (JIRA) wrote: [ https://issues.apache.org/jira/browse/UIMA-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579625#action_12579625 ] Adam Lally commented on UIMA-911: - I don't think this is a bug. This is meant to work the same as Java Iterators. If you call an iterator's hasNext() method twice, it gives you the same value and does not advance the iterator. +1. I don't think we want to change the contract for this to one which guarantees hasNext can only be called once. -Marshall
Re: [jira] Commented: (UIMA-911) CasMultiplier's hasNext() called twice without an intervening next()
At various times in our docs we indicate that the framework always calls next after hasNext, and indicate that it doesn't matter in which the processing is done, e.g. in the tutorial: Note that if it is more convenient you can request an empty CAS during the process or hasNext methods, not just during the next method. ... Instead, you should spread your processing out across the calls to the hasNext or next methods. I see no contract that says hasNext may be called more than once before next, only implicit examples of next always being called after hasNext returns true. So we're not violating anything with the current implementation but with one small change we can make things much easier for CAS Multiplier writers and reduce their errors. I have had to work around this in the past but managed to forget it last week and wasted time rediscovering the problem. Burn.
[jira] Created: (UIMA-912) UIMA C++ service not deployed correctly
UIMA C++ service not deployed correctly --- Key: UIMA-912 URL: https://issues.apache.org/jira/browse/UIMA-912 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Fix For: 2.2.2S UimaCppServiceController needs to notify deployer when initialization is finished -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
Actually I removed it deliberately as the removeAnalysisEngines method returns a void so I didn't see how it could respond that the disable should become terminate ... unlike the other over-riding method continueOnFailure which returns a boolean. But then I noticed that the Javadocs for the FlowController Interface actually suggests throwing an exception: Also the FlowController may throw an Exception if it determines that it does not make sense for the flow to continue in the absence of the removed Analysis Engines (see AnalysisEngineProcessException.FLOW_CANNOT_CONTINUE_AFTER_REMOVE. So in my last patch I suggested: Note that when disabling, the framework asks the flow controller to remove the delegate from the flow, but if the flow controller cannot reasonably operate without this component it can convert the action to 'terminate' by throwing an exception. Perhaps we could also refer to the appropriate Javadocs. - Burn On Sun, Mar 16, 2008 at 11:31 AM, Eddie Epstein [EMAIL PROTECTED] wrote: On Sat, Mar 15, 2008 at 8:12 PM, Marshall Schor [EMAIL PROTECTED] wrote: The documentation fixes include changing what happens when a disable action occurs. It use to say that ... When disabling, the framework asks the flow controller to remove the delegate from the flow; the flow controller may respond to the framework that it cannot reasonably operate without this component, in which case the framework will convert the disable into a terminate. ... This was removed. It seems to me that this was a good design. I think this is a case where the documentation is being made to match the implementation, when, perhaps, we should be making the implementation match the documentation, or at least, leaving the documentation, as it was, but perhaps including a not-yet-implemented flag. -Marshall Sorry, the paragraph removed is good and does reflect the implementation. Burn had removed it, probably by accident, and I had meant to add it back. Good catch. Eddie
[jira] Created: (UIMA-913) cleanup and simplify C++ service wrapper implementation
cleanup and simplify C++ service wrapper implementation --- Key: UIMA-913 URL: https://issues.apache.org/jira/browse/UIMA-913 Project: UIMA Issue Type: Bug Components: C++ Framework Reporter: Bhavani Iyer Some cleanup and simplificaiton of code that handles service initialization and manages ActivMQ JMS connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-845) UIMA-AS client doesnt recover from failed connection to a temp queue
[ https://issues.apache.org/jira/browse/UIMA-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-845: Description: UIMA-As client should try to recreate a temp queue as part of a silent recovery when a connection to the previously used temp queue is broken. DEFER to after 2.2.2 (was: UIMA-As client should try to recreate a temp queue as part of a silent recovery when a connection to the previously used temp queue is broken. ) UIMA-AS client doesnt recover from failed connection to a temp queue Key: UIMA-845 URL: https://issues.apache.org/jira/browse/UIMA-845 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik UIMA-As client should try to recreate a temp queue as part of a silent recovery when a connection to the previously used temp queue is broken. DEFER to after 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] Closed: (UIMA-809) Silence exceptions occuring in ActiveMQ/Spring when stopping listeners
[ https://issues.apache.org/jira/browse/UIMA-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-809. --- Resolution: Fixed Silence exceptions occuring in ActiveMQ/Spring when stopping listeners -- Key: UIMA-809 URL: https://issues.apache.org/jira/browse/UIMA-809 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Priority: Minor Fix For: 2.2.2S Attachments: uimaj-as-activemq-UIMA-809 -patch.txt, uimaj-as-core-UIMA-809 -patch.txt While stopping uima as listeners ActiveMQ/Spring sometimes generate exceptions. Need to find a way to silence these, especially in the testcases. The testcases test service shutdown in the middle of the run and the tests should not show low level exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-908) The Flow's aborted method is called when every CAS reaches the end of its flow ... should be just the failing ones
[ https://issues.apache.org/jira/browse/UIMA-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik updated UIMA-908: --- Attachment: uimaj-as-core-UIMA-908-patch.txt Removed a call to flow.aborted() from the dropCAS() method. The Flow's aborted method is called when every CAS reaches the end of its flow ... should be just the failing ones -- Key: UIMA-908 URL: https://issues.apache.org/jira/browse/UIMA-908 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2S Reporter: Burn Lewis Priority: Minor Fix For: 2.2.2S Attachments: uimaj-as-core-UIMA-908-patch.txt From the Javadocs: void aborted() Called by the framework if processing has been aborted for the CAS that was being routed by this Flow object. No further processing will take place on the CAS after this method is called, so the framework will not call the next() method again. Presumably should be called if continueOnRetryFailure attribute is false or if continueOnFailure method returns false -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-913) cleanup and simplify C++ service wrapper implementation
[ https://issues.apache.org/jira/browse/UIMA-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-913: -- Attachment: UIMA-913.patch cleanup and simplify C++ service wrapper implementation --- Key: UIMA-913 URL: https://issues.apache.org/jira/browse/UIMA-913 Project: UIMA Issue Type: Bug Components: C++ Framework Reporter: Bhavani Iyer Attachments: UIMA-913.patch Some cleanup and simplificaiton of code that handles service initialization and manages ActivMQ JMS connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-908) The Flow's aborted method is called when every CAS reaches the end of its flow ... should be just the failing ones
[ https://issues.apache.org/jira/browse/UIMA-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-908. -- Resolution: Fixed The Flow's aborted method is called when every CAS reaches the end of its flow ... should be just the failing ones -- Key: UIMA-908 URL: https://issues.apache.org/jira/browse/UIMA-908 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2S Reporter: Burn Lewis Priority: Minor Fix For: 2.2.2S Attachments: uimaj-as-core-UIMA-908-patch.txt From the Javadocs: void aborted() Called by the framework if processing has been aborted for the CAS that was being routed by this Flow object. No further processing will take place on the CAS after this method is called, so the framework will not call the next() method again. Presumably should be called if continueOnRetryFailure attribute is false or if continueOnFailure method returns false -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-914) If the Error Configuration thresholdWindow value is invalid it is quietly ignored
If the Error Configuration thresholdWindow value is invalid it is quietly ignored - Key: UIMA-914 URL: https://issues.apache.org/jira/browse/UIMA-914 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2S Reporter: Burn Lewis Priority: Trivial Fix For: 2.2.2S If the thresholdWindow value is 0 but is less than the thresholdCount value then the error condition can never be satisfied. The current implementation ignores the window value in this case, but we should warn the user or reject these invalid values or document this behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-911) CasMultiplier's hasNext() called twice without an intervening next()
[ https://issues.apache.org/jira/browse/UIMA-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-911: Attachment: UIMA-911-fix.patch But this is different ... the user's code is implementing an iterator that the the UIMA framework is using. The attached fix changes just a few lines in the AnalysisComponentCasIterator class. Note that the CPE gets it right when calling collection readers so existing CRs may break when wrapped as CasMultipliers. We should at least spell it out in the CAS Multiplier contract: The framework guarantees that it will not call next unless hasNext has returned true since the last call to process or next , but it may call hasNext even if next has not been called since the last call to hasNext. And similar warnings where we suggest doing some of the processing in hasNext. CasMultiplier's hasNext() called twice without an intervening next() Key: UIMA-911 URL: https://issues.apache.org/jira/browse/UIMA-911 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Burn Lewis Priority: Minor Attachments: UIMA-911-fix.patch, UIMA-911.patch In org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl the hasNext method calls the AnalysisComponent's hasNext but then its next method calls the AnalysisComponent's hasNext again before calling next. Makes it difficult to split the processing between hasNext next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis updated UIMA-838: Attachment: UIMA-838-fix2.patch Sorry to say my fix didn't handle the thresholdWindow == thresholdCount case i.e. when the action should be taken after thresholdCount consecutive errors. The current implementation treats this as if there were no window, counting total errors. Incorrect support for process CAS error threshold count and threshold window - Key: UIMA-838 URL: https://issues.apache.org/jira/browse/UIMA-838 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Burn Lewis Fix For: 2.2.2S Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-fix2.patch, UIMA-838-test.patch, UIMA-838.patch The thresholdAction should be taken when the number of CAS errors reaches the thresholdCount value within the last thresholdWindow CASes. A thresholdWindow of 0 means an infinite window, so the action is taken when the total number of errors reaches the thresholdCount. A thresholdCount of 0 means an infinite limit, errors are ignored. A thresholdCount of 1 means that the first error triggers the action, hence the action must be taken when the threshold is REACHED, not exceeded as stated in the current docs. (Although thresholds usually apply when exceeded, making the thresholdCount be the number permitted would require using a value such as -1 for no threshold, in contrast to our use of 0 to mean no timeout and no window) It should be an error to specify a (non-zero) thresholdWindow that is smaller than the thresholdCount ... an impossible situation. Note that if thresholdCount = 1 the thresholdWindow value is irrelevant, and if thresholdCount = thresholdWindow the action is taken when that many consecutive errors occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-915) Clean up README for UIMA AS SDK
Clean up README for UIMA AS SDK --- Key: UIMA-915 URL: https://issues.apache.org/jira/browse/UIMA-915 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Fix For: 2.2.2S -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
