RE: possibly including the BSFAnnotator in the sandbox release 2.3.0
Hi Marshall When I donated the BSFAnnotator about two years ago I was not very familiar with the maven-based Apache UIMA build process... And I'm afraid I'm still not be. While working on including the BSFAnnotator in the sandbox release, I noticed it has 6 jar files in its lib directory. The NOTICE file says that the project includes some components under MPL and SPL; however, the information needed to associate each of this included 3rd-party jar files with the proper license is missing. Can someone who knows identify the source of the following jars: bsf.jar Apache 2 license Comes from http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip bsh-bsf.jar No longer needed: can be removed bsh.jar Dual licensed under both the SPL and LGPL = SPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now contains the bsh-bsf.jar classes) commons-logging-api-1.1.jar Apache 2 license Comes from http://archive.apache.org/dist/commons/logging/binaries/commons-logging- 1.1.zip js.jar Dual licensed under both the MPL 1.1 and GPL = MPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip log4j-1.2.15.jar Apache 2 license Comes from http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 .2.15.zip Is there a better way to package / distribute this in binary form? Probably using maven dependencies but I don't have enough maven-skills to do it myself Also, I noticed that the POM section for building the documentation is commented out - because there is no docbook style documentation. The documentation seems limited to a README and some examples. Is there additional documentation available for this? No: just the README sorry I guess that a real revamping should use the JSR-223 (javax.script) which is included in Java 1.6 and add support to new popular scripting languages like groovy, beanshell 2.0 etc... -Marshall
[jira] Created: (UIMA-1505) Generics for org.apache.uima.analysis_engine classes
Generics for org.apache.uima.analysis_engine classes Key: UIMA-1505 URL: https://issues.apache.org/jira/browse/UIMA-1505 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: ResourceFactory.produceResource
Adam Lally wrote: On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmannkottm...@gmail.com wrote: The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, MapString, Object aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class? extends Resource. Yes, I think that is right. In CPEFactory a org.apache.uima.collection.base_cpm.BaseCollectionReader is used as a resource class at line 345 to call UIMAFramework.produceResource. BaseCollectionReader does not extends the Resource interface. I wonder if that is correct usage of the produceResource method. Jörn
Re: generics: ResourceFactory.produceResource
On Thu, Aug 20, 2009 at 8:11 AM, Jörn Kottmannkottm...@gmail.com wrote: Adam Lally wrote: On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmannkottm...@gmail.com wrote: The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, MapString, Object aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class? extends Resource. Yes, I think that is right. In CPEFactory a org.apache.uima.collection.base_cpm.BaseCollectionReader is used as a resource class at line 345 to call UIMAFramework.produceResource. BaseCollectionReader does not extends the Resource interface. I wonder if that is correct usage of the produceResource method. That usage doesn't seem quite right. It will only work if the implementation of BaseCollectionReader happens to also implement Resource, otherwise I think it would throw a ClassCastException in produceResource(). I'm in favor of making BaseCollectionReader extend Resource. -Adam
Re: possibly including the BSFAnnotator in the sandbox release 2.3.0
Olivier Terrier wrote: Hi Marshall When I donated the BSFAnnotator about two years ago I was not very familiar with the maven-based Apache UIMA build process... And I'm afraid I'm still not be. While working on including the BSFAnnotator in the sandbox release, I noticed it has 6 jar files in its lib directory. The NOTICE file says that the project includes some components under MPL and SPL; however, the information needed to associate each of this included 3rd-party jar files with the proper license is missing. Can someone who knows identify the source of the following jars: bsf.jar Apache 2 license Comes from http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip bsh-bsf.jar No longer needed: can be removed bsh.jar Dual licensed under both the SPL and LGPL = SPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now contains the bsh-bsf.jar classes) commons-logging-api-1.1.jar Apache 2 license Comes from http://archive.apache.org/dist/commons/logging/binaries/commons-logging- 1.1.zip js.jar Dual licensed under both the MPL 1.1 and GPL = MPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip log4j-1.2.15.jar Apache 2 license Comes from http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 .2.15.zip Is there a better way to package / distribute this in binary form? Probably using maven dependencies but I don't have enough maven-skills to do it myself Also, I noticed that the POM section for building the documentation is commented out - because there is no docbook style documentation. The documentation seems limited to a README and some examples. Is there additional documentation available for this? No: just the README sorry I guess that a real revamping should use the JSR-223 (javax.script) which is included in Java 1.6 and add support to new popular scripting languages like groovy, beanshell 2.0 etc... Thanks for responding! I'll update the project with this information. -Marshall -Marshall
[jira] Created: (UIMA-1506) update Bean Scripting Framework Annotator with info about licenses and documentation
update Bean Scripting Framework Annotator with info about licenses and documentation Key: UIMA-1506 URL: https://issues.apache.org/jira/browse/UIMA-1506 Project: UIMA Issue Type: Improvement Components: Sandbox-BSFAnnotator Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3AS update with info received in email: http://markmail.org/thread/e3q5gk6h42jggg5c -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: possibly including the BSFAnnotator in the sandbox release 2.3.0
Hi Olivier - I updated the project: removed the bsf-bsh.jar updated the bsh.jar to bsh-1.3.0.jar I changed the POM so it didn't depend on the bsf-bsh.jar and changed the dependency of the bsh.jar to bsh-1.3.0.jar. When I tried to build it, it failed when running the testAnnotatorAggregated. (The tests ran before I did these updates) The error was: caused by org.apache.bsf.BSFException: the application script threw an exception: java.lang.NullPointerException: Null Pointer in Method Invocation at bsh.util.BeanShellBSFEngine.call(Unknown Source) at org.apache.uima.annotator.bsf.BSFAnnotator.initialize(BSFAnnotator.java:161) Can you take a look? I've check in the updated project - you should be able to just check it out. Thanks. -Marshall Olivier Terrier wrote: Hi Marshall When I donated the BSFAnnotator about two years ago I was not very familiar with the maven-based Apache UIMA build process... And I'm afraid I'm still not be. While working on including the BSFAnnotator in the sandbox release, I noticed it has 6 jar files in its lib directory. The NOTICE file says that the project includes some components under MPL and SPL; however, the information needed to associate each of this included 3rd-party jar files with the proper license is missing. Can someone who knows identify the source of the following jars: bsf.jar Apache 2 license Comes from http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip bsh-bsf.jar No longer needed: can be removed bsh.jar Dual licensed under both the SPL and LGPL = SPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now contains the bsh-bsf.jar classes) commons-logging-api-1.1.jar Apache 2 license Comes from http://archive.apache.org/dist/commons/logging/binaries/commons-logging- 1.1.zip js.jar Dual licensed under both the MPL 1.1 and GPL = MPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip log4j-1.2.15.jar Apache 2 license Comes from http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 .2.15.zip Is there a better way to package / distribute this in binary form? Probably using maven dependencies but I don't have enough maven-skills to do it myself Also, I noticed that the POM section for building the documentation is commented out - because there is no docbook style documentation. The documentation seems limited to a README and some examples. Is there additional documentation available for this? No: just the README sorry I guess that a real revamping should use the JSR-223 (javax.script) which is included in Java 1.6 and add support to new popular scripting languages like groovy, beanshell 2.0 etc... -Marshall
[jira] Created: (UIMA-1507) BaseCollectionReader should extend Resource
BaseCollectionReader should extend Resource --- Key: UIMA-1507 URL: https://issues.apache.org/jira/browse/UIMA-1507 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 To allow a call to produceResource to create a BaseCollectionReader, it must extend the Resource interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1508) Generify uimaj-core
Generify uimaj-core --- Key: UIMA-1508 URL: https://issues.apache.org/jira/browse/UIMA-1508 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Fix For: 2.3 Parent issue for all generification issues for uimaj-core to keep track of all changes and the overall progress. All generification issues should specify this issue as parent issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: possibly including the BSFAnnotator in the sandbox release 2.3.0
OK I have a look Cheers Olivier -Message d'origine- De : Marshall Schor [mailto:m...@schor.com] Envoyé : jeudi 20 août 2009 16:52 À : uima-dev@incubator.apache.org Objet : Re: possibly including the BSFAnnotator in the sandbox release 2.3.0 Hi Olivier - I updated the project: removed the bsf-bsh.jar updated the bsh.jar to bsh-1.3.0.jar I changed the POM so it didn't depend on the bsf-bsh.jar and changed the dependency of the bsh.jar to bsh-1.3.0.jar. When I tried to build it, it failed when running the testAnnotatorAggregated. (The tests ran before I did these updates) The error was: caused by org.apache.bsf.BSFException: the application script threw an exception: java.lang.NullPointerException: Null Pointer in Method Invocation at bsh.util.BeanShellBSFEngine.call(Unknown Source) at org.apache.uima.annotator.bsf.BSFAnnotator.initialize(BSFAnnotator.java :161) Can you take a look? I've check in the updated project - you should be able to just check it out. Thanks. -Marshall Olivier Terrier wrote: Hi Marshall When I donated the BSFAnnotator about two years ago I was not very familiar with the maven-based Apache UIMA build process... And I'm afraid I'm still not be. While working on including the BSFAnnotator in the sandbox release, I noticed it has 6 jar files in its lib directory. The NOTICE file says that the project includes some components under MPL and SPL; however, the information needed to associate each of this included 3rd-party jar files with the proper license is missing. Can someone who knows identify the source of the following jars: bsf.jar Apache 2 license Comes from http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip bsh-bsf.jar No longer needed: can be removed bsh.jar Dual licensed under both the SPL and LGPL = SPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now contains the bsh-bsf.jar classes) commons-logging-api-1.1.jar Apache 2 license Comes from http://archive.apache.org/dist/commons/logging/binaries/commons- logging- 1.1.zip js.jar Dual licensed under both the MPL 1.1 and GPL = MPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip log4j-1.2.15.jar Apache 2 license Comes from http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache- log4j-1 .2.15.zip Is there a better way to package / distribute this in binary form? Probably using maven dependencies but I don't have enough maven- skills to do it myself Also, I noticed that the POM section for building the documentation is commented out - because there is no docbook style documentation. The documentation seems limited to a README and some examples. Is there additional documentation available for this? No: just the README sorry I guess that a real revamping should use the JSR-223 (javax.script) which is included in Java 1.6 and add support to new popular scripting languages like groovy, beanshell 2.0 etc... -Marshall
[jira] Closed: (UIMA-1292) Uima AS Jms Listener Should Support Retry When Establishing Connection To a Broker
[ https://issues.apache.org/jira/browse/UIMA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1292. --- Resolution: Fixed The listener failed to recover from a lost broker because of the maxInactivityDuration=0 parameter in the broker URL. This effectively turns off ability to detect socket closure and causing a service to sit on a stale connection. No messages flow into the service even if a new broker becomes available. Modified the listener to accept broker URL as provided by a user. Removed check for existence of maxInactivityDuration=0. If there are problems with socket closing due to inactivity use keepAlive=true parameter in the broker URL instead of maxInactivityDuration=0. Example: tcp://host:61616?keepAlive=true. This turns on low level socket keep alive protocol which sends small packets and awaits ACKs. The frequency of these packets can be changed on linux by editing this file: /proc/sys/net/ipv4/tcp_keepalive_intvl. The default frequency on linux is 75 seconds Uima AS Jms Listener Should Support Retry When Establishing Connection To a Broker -- Key: UIMA-1292 URL: https://issues.apache.org/jira/browse/UIMA-1292 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik UIMA AS service should support retry when a listener on the service input queue fails due to a broker not being available. The listener should log a message stating the fact that the broker is not available and it should enter a loop attempting to reconnect. When a broker becomes available the listener should reconnect, log a message that the connection was made, and proceed to complete initialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1439) Fix interemittent hangs in UIMA AS when stopping the JMS listener
[ https://issues.apache.org/jira/browse/UIMA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1439. --- Resolution: Fixed Fixed under JIRA UIMA-1433. Bug in caching JMS connections prevented cleanup code from stopping AMQ threads. Fix interemittent hangs in UIMA AS when stopping the JMS listener - Key: UIMA-1439 URL: https://issues.apache.org/jira/browse/UIMA-1439 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik When stopping UIMA AS listener, the ThreadPoolTaskExecutor shutdown method is called and the code than waits for all threads managed by the executor to stop. The problem is that listener's stop method may be called from one of the threads that are being managed by the executor. The executor tries to stop the thread and the thread tries to stop the executor. This leads to a hang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1434) UIMA AS logs an exception when handling stale messages
[ https://issues.apache.org/jira/browse/UIMA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1434. --- Resolution: Fixed UIMA AS logs an exception when handling stale messages -- Key: UIMA-1434 URL: https://issues.apache.org/jira/browse/UIMA-1434 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Priority: Minor Stale messages should not be logged with an exception. Messages can become stale for a number of reasons and should not be logged as a warning. Instead of an exception, a message should be logged to indicate that the stale message was processed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1509) Generify the aResourceClass Class through the uimaj-core codebase
Generify the aResourceClass Class through the uimaj-core codebase - Key: UIMA-1509 URL: https://issues.apache.org/jira/browse/UIMA-1509 Project: UIMA Issue Type: Improvement Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 It should be declared as Class? extends Resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1480) Add version compatibility verification to UIMA-AS for base UIMA level
[ https://issues.apache.org/jira/browse/UIMA-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1480. --- Resolution: Fixed Modified UIMA-AS client and UIMA AS Service Controller's base class to check for version compatibility between UIMA-AS and UIMA Core. The code checks for exact match. Add version compatibility verification to UIMA-AS for base UIMA level - Key: UIMA-1480 URL: https://issues.apache.org/jira/browse/UIMA-1480 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Marshall Schor Assignee: Jerry Cwiklik Fix For: 2.3AS As part of the repackaging of UIMA-AS, it won't necessarily be packaged with a version of base UIMA - so it should verify that the version of base UIMA it is running with is OK. For now, require that it be at the corresponding level that is released - e.g., 2.3.0 for the Base and 2.3.0 for UIMA-AS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1269) NPE when using a C++ service deployed via JNI
[ https://issues.apache.org/jira/browse/UIMA-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1269: Assignee: Bhavani Iyer 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 Assignee: Bhavani Iyer 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] Assigned: (UIMA-1328) deployAsyncService.sh causes Log4j FileNotFoundException
[ https://issues.apache.org/jira/browse/UIMA-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1328: Assignee: Jerry Cwiklik deployAsyncService.sh causes Log4j FileNotFoundException Key: UIMA-1328 URL: https://issues.apache.org/jira/browse/UIMA-1328 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.3AS Environment: Ubuntu 8.10 Reporter: Jörn Kottmann Assignee: Jerry Cwiklik The following exception is printed to the console during startup: bin/deployAsyncService.sh tagger/desc/Deploy_TextAnalysis.xml Setting defaultBrokerURL to: log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: /activemq-data/activemq.log (No such file or directory) at java.io.FileOutputStream.openAppend(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:177) at java.io.FileOutputStream.init(FileOutputStream.java:102) at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:156) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:247) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:123) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:645) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:603) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:500) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:406) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:432) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:460) at org.apache.log4j.LogManager.clinit(LogManager.java:113) at org.apache.log4j.Category.getInstance(Category.java:514) at org.apache.commons.logging.impl.Log4JCategoryLog.init(Log4JCategoryLog.java:100) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:502) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:285) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:255) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:381) at org.springframework.util.ClassUtils.clinit(ClassUtils.java:67) at org.springframework.core.io.DefaultResourceLoader.init(DefaultResourceLoader.java:52) at org.springframework.context.support.AbstractApplicationContext.init(AbstractApplicationContext.java:184) at org.springframework.context.support.AbstractRefreshableApplicationContext.init(AbstractRefreshableApplicationContext.java:80) at org.springframework.context.support.AbstractXmlApplicationContext.init(AbstractXmlApplicationContext.java:58) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:91) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:77) at org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:370) at org.apache.uima.adapter.jms.service.UIMA_Service.deploy(UIMA_Service.java:170) at org.apache.uima.adapter.jms.service.UIMA_Service.main(UIMA_Service.java:406) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1295) Add continue as an error handling option for getMeta at initialization
[ https://issues.apache.org/jira/browse/UIMA-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1295: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release Add continue as an error handling option for getMeta at initialization Key: UIMA-1295 URL: https://issues.apache.org/jira/browse/UIMA-1295 Project: UIMA Issue Type: New Feature Components: Async Scaleout Affects Versions: 2.3AS Reporter: Eddie Epstein In http://markmail.org/message/ceb2npk5qsmuftn4 Yosi Mass requested that UIMA support a peer-to-peer capability where services are discovered dynamically to improve load balancing, and presumably, to enhance processing by using analytics which only become available after a client has started. UIMA AS already supports dynamically expanding processing capability for a particular service, by simply starting additional service instances pointed at the service's existing request queue. Using appropriate error handling and/or custom flow controller options, a UIMA AS aggregate also has the capability to ignore a missing delegate service, as long as the delegate service was available during aggregate initialization. The enhancement suggested here is to allow an aggregate service to later use a delegate service that was unavailable during initialization. UIMA changes would be: 1. add a new error handling option for getMeta failures at initialization. Currently the options at init are to disable any use of the delegate, or fail initialization and terminate the aggregate. The new option, continue, would be ignore this failure and complete initialization of the aggregate, but mark the delegate as being in a special state, very similar to the questionable state described in UIMA-1127. 2. The difference from UIMA-1127 is that when getMeta succeeds for this delegate, the service's type system would be checked to see that it is compatible with that of the aggregate. See UIMA-1290 for details on what validation means. If valid, the delegate is marked fully operational. If the type system fails validation, and process error handling is set to continue, a new exception type would be given to the flow controller to decide how to handle the situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1227) Help users debug binary CAS serialization problems
[ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1227: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release - requires changes to core to support comparing type systems 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 Affects Versions: 2.3AS 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] Updated: (UIMA-1405) Uima AS not allowing deployment of more than one deployment descriptor in the same jvm
[ https://issues.apache.org/jira/browse/UIMA-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1405: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release Uima AS not allowing deployment of more than one deployment descriptor in the same jvm -- Key: UIMA-1405 URL: https://issues.apache.org/jira/browse/UIMA-1405 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.3AS Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Priority: Minor Uima AS fails with ResourceInitializationException when one tries to deploy more than one deployment descriptor using deployAsyncService script. The problem is that components in generated spring context files are deployed into a single Spring container. But each spring context files defines singleton objects that are not meant to be used externally. An example of such non-shared singleton would the InProcessCache. It is meant to be shared by components defined in a single context file. There are few possibly solutions here: 1) modify dd2spring to assign unique names to spring beans to prevent sharing across context files. 2) modify uima-as deployer to deploy each context file in a separate spring container 3) find a way to prevent spring from sharing singleton objects across context files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
[ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1358: Assignee: Jerry Cwiklik (was: Burn Lewis) 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 Assignee: Jerry Cwiklik Fix For: 2.3S Attachments: uimaj-as-activemq_1358.patch 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() Child1 ID-of-Child1ID-of-Parent false Child2 ID-of-Child2ID-of-Parent false Parent ID-of-Parentnull false If the 2nd child causes an exception then the client might see (Option A) returnedCAS getCasReferenceId() getParentCasReferenceId() isException() Child1 ID-of-Child1ID-of-Parent false nullID-of-Parentnull true Or we could put the failing child's ID in the status (Option B) returnedCAS getCasReferenceId() getParentCasReferenceId() isException() Child1 ID-of-Child1ID-of-Parent false nullID-of-Child2ID-of-Parent true 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
[jira] Assigned: (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:all-tabpanel ] Marshall Schor reassigned UIMA-1297: Assignee: Burn Lewis (was: Jerry Cwiklik) 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: Burn Lewis Attachments: uimaj-as-activemq_1297.patch 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] Assigned: (UIMA-1288) Need a Better Approach For Specifying UIMA AS Broker URL in Deployment Descriptor
[
https://issues.apache.org/jira/browse/UIMA-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reassigned UIMA-1288:
Assignee: Tong Fin (was: Eddie Epstein)
Need a Better Approach For Specifying UIMA AS Broker URL in Deployment
Descriptor
-
Key: UIMA-1288
URL: https://issues.apache.org/jira/browse/UIMA-1288
Project: UIMA
Issue Type: Improvement
Components: Async Scaleout
Reporter: Jerry Cwiklik
Assignee: Tong Fin
Each UIMA AS deployment descriptor requires at least one Broker URL for the
connection factory. Instead of hard coding the URL, perhaps a placeholder for
it should be used. At runtime, the placeholder could be resolved to the
actual URL by Spring resolver component. The value could come from either an
external file or from an environment. The new approach should accommodate
specifying more than one placeholder, since an aggregate may have delegates
whose queues are managed by a different broker. The new approach would
simplify deployment of UIMA AS services, especially during testing.
A placeholder syntax could be inherited from Spring, where it looks like
${placeholder-name}.
dd2spring would need to change to handle a placeholder notation in addition
to supporting hard coded broker URL that we use now. A new bean must be added
to the generated xml. It will be :
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=systemPropertiesModeName
value=SYSTEM_PROPERTIES_MODE_OVERRIDE/
/bean
This bean is setup to resolve placeholders using system variables, like
-Dplaceholder-name=placeholder-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1278) Add ability to report JMS reconnection status
[ https://issues.apache.org/jira/browse/UIMA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1278: - Affects Version/s: 2.3AS defer beyond 2.3.0 release Add ability to report JMS reconnection status - Key: UIMA-1278 URL: https://issues.apache.org/jira/browse/UIMA-1278 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.3AS Reporter: Bhavani Iyer Assignee: Bhavani Iyer The ControllerCallbackListener needs to be extended to provide APIs to report JMS reconnection status. At present this status is reported by C++ services via the UimacppServiceController bean, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1298) A shared remote CM hangs when one of its clients runs out of memory
[ https://issues.apache.org/jira/browse/UIMA-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1298: - Affects Version/s: 2.3AS defer beyond 2.3.0 release 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 Affects Versions: 2.3AS 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] Closed: (UIMA-1487) Add support for collectionProcessComplete timeout setting in JMS service adapter
[ https://issues.apache.org/jira/browse/UIMA-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1487. --- Resolution: Fixed Fixed by Eddie Add support for collectionProcessComplete timeout setting in JMS service adapter Key: UIMA-1487 URL: https://issues.apache.org/jira/browse/UIMA-1487 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Assignee: Eddie Epstein The JMS service adapter is used to allow UIMA aggregates to call UIMA AS services, similar to Vinci and SOAP services. The JMS adapter supports process and getmeta timeouts, but not CPC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1298) A shared remote CM hangs when one of its clients runs out of memory
[ https://issues.apache.org/jira/browse/UIMA-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745597#action_12745597 ] Jerry Cwiklik commented on UIMA-1298: - Consider spinning a thread in the CM service that periodically checks outgoing connections to detect failed clients. Perhaps sending a Ping message to a client can be used to detect stale connections and dead clients. 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 Affects Versions: 2.3AS 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] Closed: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
[ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1358. --- Resolution: Fixed Applied Burn's patch 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 Assignee: Jerry Cwiklik Fix For: 2.3S Attachments: uimaj-as-activemq_1358.patch 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() Child1 ID-of-Child1ID-of-Parent false Child2 ID-of-Child2ID-of-Parent false Parent ID-of-Parentnull false If the 2nd child causes an exception then the client might see (Option A) returnedCAS getCasReferenceId() getParentCasReferenceId() isException() Child1 ID-of-Child1ID-of-Parent false nullID-of-Parentnull true Or we could put the failing child's ID in the status (Option B) returnedCAS getCasReferenceId() getParentCasReferenceId() isException() Child1 ID-of-Child1ID-of-Parent false nullID-of-Child2ID-of-Parent true 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
[jira] Closed: (UIMA-1510) improve uimaj-distr assembly
[ https://issues.apache.org/jira/browse/UIMA-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1510. Resolution: Fixed improve uimaj-distr assembly Key: UIMA-1510 URL: https://issues.apache.org/jira/browse/UIMA-1510 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 2.3 change POM to POM style (from Jar style) - previous problem seems to have gone away which required Jar style. This way, no extraneous jar file is generated. update dependency sets with useProjectArtifact = false to avoid 18 warning messages. factor out version/scope from dependency sets use current level of JavaDoc generation tool (works much faster, is preset to Java 5 in parent poms, etc.) use current level of assembly plugin 2.2-beta-4, up from 2.2-beta-2 drop bz2 formats -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-319) Annotator and Analysis Engine Guide Other Examples section may be misplaced
[ https://issues.apache.org/jira/browse/UIMA-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-319: Affects Version/s: (was: 2.2) (was: 2.1) 2.3 Annotator and Analysis Engine Guide Other Examples section may be misplaced - Key: UIMA-319 URL: https://issues.apache.org/jira/browse/UIMA-319 Project: UIMA Issue Type: Improvement Components: Documentation Affects Versions: 2.3 Reporter: Adam Lally Priority: Trivial Annotator and Analysis Engine Guide has Other Examples section that mentions a CAS Consumer, but the concept of CAS Consumers hasn't been introduced yet. Perhaps this section belongs in the CPE Developer's Guide instead? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1501) more refactoring and updating - parent POMs
[ https://issues.apache.org/jira/browse/UIMA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1501: Assignee: Marshall Schor more refactoring and updating - parent POMs --- Key: UIMA-1501 URL: https://issues.apache.org/jira/browse/UIMA-1501 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor use pluginManagement and dependencyManagement to refactor additional items. Update to javadoc plugin 2.5 (the current level - what the superPom specifies). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
