Re: source files packaging
On Sep 1, 2009, at 4:42 AM, Adam Lally wrote: On Sat, Aug 29, 2009 at 1:00 PM, Jörn Kottmannkottm...@gmail.com wrote: On Aug 28, 2009, at 3:14 PM, Marshall Schor wrote: We could do this for all of our Jars, and I'm thinking this would be a good idea. One reason would be it would align us slightly better with the maven way of doing things. When users download jars from maven they would find the sources rather than get maven warning messages that no sources were found, and the m2eclipse plugin would easily be able to get the sources. +1 Yes I would really appreciate having the source code in eclipse linked to the uiima jars automatically with mvn eclipse:eclipse. I'm not sure I completely understand - does this mean our binary distributions contain source, or not? If so, I am uneasy about that. We had this discussion prior to the last release without a real consensus being reached: http://markmail.org/thread/oqredcsn3camvyy7. To have source code linked in eclipse a binary (the one we have now) and separate source jars must be published via maven. Jörn
[jira] Commented: (UIMA-1342) Use @Deprecated annotation also
[ https://issues.apache.org/jira/browse/UIMA-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749802#action_12749802 ] Jörn Kottmann commented on UIMA-1342: - Only did it fore uimaj-core up to now, but I can do it for the other code too today. Use @Deprecated annotation also --- Key: UIMA-1342 URL: https://issues.apache.org/jira/browse/UIMA-1342 Project: UIMA Issue Type: Improvement Reporter: Jörn Kottmann Assignee: Jörn Kottmann Priority: Trivial Currently only the @deprecated javadoc tag is used to indicate deprecation, but it is not guaranteed to issue a compiler warning in client code, though the sun java compiler does it. To fix it we can just add the @Deprecate annotation additional which is specified to issue a compiler warning and is supported since java 1.5. I suggest that we use the eclipse code clean up tool to do it once for all code in our repository. For further information see: http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/deprecation/deprecation.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: source files packaging
Hi, On Fri, Aug 28, 2009 at 3:14 PM, Marshall Schorm...@schor.com wrote: Should we adopt this approach? +1 Source jars in the Maven repository are very convenient. This practice is quickly becoming more common within Apache. See the latest org.apache:apache parent POM [1] that by default attaches source and javadoc jars to a release build. [1] http://repo2.maven.org/maven2/org/apache/apache/6/apache-6.pom BR, Jukka Zitting
[jira] Closed: (UIMA-1452) add generic type info to some classes in uima-core
[ https://issues.apache.org/jira/browse/UIMA-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann closed UIMA-1452. --- Resolution: Fixed Closed now, all code which still needs generification should be cheked-in with specific jira issues. add generic type info to some classes in uima-core -- Key: UIMA-1452 URL: https://issues.apache.org/jira/browse/UIMA-1452 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Marshall Schor Assignee: Jörn Kottmann Priority: Trivial Fix For: 2.3 Manually examine and add generic type arguments to some classes in uima-core that resist the Eclipse infer generic arguments method. (Resist - means that when you do that operation, you get some errors, e.g., two methods with same erasure) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Still a uima-as directory in the sandbox
I expect this is just a left-over and can be deleted? --Thilo
Re: Still a uima-as directory in the sandbox
+1 2009/9/1 Thilo Goetz twgo...@gmx.de I expect this is just a left-over and can be deleted? --Thilo
[jira] Closed: (UIMA-1152) Match group counting does not work properly with escaped open bracket within variables.
[ https://issues.apache.org/jira/browse/UIMA-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz closed UIMA-1152. - Resolution: Invalid I created some more tests, and they all run as expected. Maybe there's some misunderstanding here about the escaping rules in character classes? [\s,\.:;\[\]\(\)] doesn't make much sense, all the backslashes don't have their probably intended effect, except for \] and \[. If this is really a problem, please create a test case that allows us to understand what's going wrong here. Thanks. Match group counting does not work properly with escaped open bracket within variables. --- Key: UIMA-1152 URL: https://issues.apache.org/jira/browse/UIMA-1152 Project: UIMA Issue Type: Bug Components: Sandbox-RegexAnnotator Affects Versions: 2.2.2S, 2.3S Environment: Windows XP Reporter: Mateusz Wiacek Priority: Minor Example: variable name=varPunctMarks value=[\s,\.:;\[\]\(\)]/ Escaped open bracket should not be recognized as matching group, but it does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: source files packaging
Adam Lally wrote: On Sat, Aug 29, 2009 at 1:00 PM, Jörn Kottmannkottm...@gmail.com wrote: On Aug 28, 2009, at 3:14 PM, Marshall Schor wrote: We could do this for all of our Jars, and I'm thinking this would be a good idea. One reason would be it would align us slightly better with the maven way of doing things. When users download jars from maven they would find the sources rather than get maven warning messages that no sources were found, and the m2eclipse plugin would easily be able to get the sources. +1 Yes I would really appreciate having the source code in eclipse linked to the uiima jars automatically with mvn eclipse:eclipse. I'm not sure I completely understand - does this mean our binary distributions contain source, or not? If so, I am uneasy about that. We had this discussion prior to the last release without a real consensus being reached: http://markmail.org/thread/oqredcsn3camvyy7. No, the binary assemblies produced by our builds would not have the sources. What would change is that the maven artificat distribution servers would have, in addition to our Jars, the Sources that go with those Jars. We still have the approach for people not using Maven, of having separate sources, which can be downloaded (or not), and if downloaded, can be added to the Jars directly. -Marshall -Adam
Re: Still a uima-as directory in the sandbox
Thilo Goetz wrote: I expect this is just a left-over and can be deleted? Here's a possible reason to leave this: users can get the history of this folder, and find older releases, where they might expect them. I'm ok with removing it though, if that's the more normal, less confusing approach. -Marshall --Thilo
Re: UIMA AS client CPU load
Posted it a few days ago, would be nice if someone
could have a look. I assume there is a wait missing, right ?
If so the fix is simple and we can include it in 2.3.0.
Jörn
Jörn Kottmann wrote:
Hi everyone,
to put some load on one of our UIMA AS system I wrote
a small tool which uses the client API to send CASes to
a processing pipeline.
This tool has an endless loop which waits for work
to arrive and then sends it to the processing pipeline.
It basically looks like this:
text = getNextDocument() // returns plain text which should be analyzed
CAS cas = uimASEngine.getCAS();
cas.setDocumentText(text)
uimaAsEngine.sendCAS(cas)
When the tool is started there is usually lots of work waiting
and all available CASes are sent out to the service. It takes a while
until the first CAS is completly processed. Now the
tool gets a new text and waits for a new CAS inside getCAS().
Now I wonder why waiting for a CAS inside getCAS() puts 95 to 100 %
CPU load
on one core on my client machine.
I looked at the place where it waits in
BaseUIMAAsynchronousEngineCommon_impl
around line 536 in getCAS().
Here is the wait loop:
while (running) {
try {
// Wait until the CAS producer adds the CAS to the
CasQueueEntry and
// signals CAS availability.
entry.getSemaphore().acquire();
if (entry.getCas() == null) {
continue;
} else {
return entry.getCas();
}
} finally {
entry.getSemaphore().release();
} } // while
For me it looks like that if entry.getCAS() returns null it immediately
tries again and polls entry.getCAS() as often as possible.
Jörn
Re: Still a uima-as directory in the sandbox
Marshall Schor wrote: Thilo Goetz wrote: I expect this is just a left-over and can be deleted? Here's a possible reason to leave this: users can get the history of this folder, and find older releases, where they might expect them. I'm no subversion expert, but I think since you moved uima-as in subversion, all the history is there and keeping this folder serves no purpose. I'm ok with removing it though, if that's the more normal, less confusing approach. -Marshall --Thilo
[jira] Closed: (UIMA-1399) Deployment of C++ service ignores environmentVariable name=UIMACPP_STARTING_DIRECTORY
[ https://issues.apache.org/jira/browse/UIMA-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-1399. --- Resolution: Fixed Yes, fix was committed back in June. Deployment of C++ service ignores environmentVariable name=UIMACPP_STARTING_DIRECTORY - Key: UIMA-1399 URL: https://issues.apache.org/jira/browse/UIMA-1399 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Assignee: Eddie Epstein UIMA AS deployment descriptors allow specification of the starting directory for external processes launched by Java. Currently this element is ignored by UimacppServiceController -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r808996 - /incubator/uima/uimaj/trunk/uimaj-bootstrap/
Thilo Goetz wrote: Marshall Schor wrote: The reason for a new project was to isolate the classes in the normal -cp class path to just this one class :-). This is a general purpose launcher, that could also be used to simplify our base launching scripts. I think we would be doing our users a disservice. I just fixed the pear runner not to go ahead an use any jar file it finds in the lib directory. That kind of defaulty behavior has surprising and undesirable effects. Well, at least this is optional in some sense. But other projects I see are using this approach (ActiveMQ for instance). Is there another simple approach to aggregating lots of Jar files, other than long lists of them in some file? -Marshall -Marshall Thilo Goetz wrote: sc...@apache.org wrote: Author: schor Date: Fri Aug 28 19:28:58 2009 New Revision: 808996 URL: http://svn.apache.org/viewvc?rev=808996view=rev Log: [UIMA-1536] initial import, moved from uimaj-tools Added: incubator/uima/uimaj/trunk/uimaj-bootstrap/ We create a new project just for this? Am I correct in assuming that only UIMA-AS needs this? Why don't we put it there then? --Thilo
Re: Still a uima-as directory in the sandbox
Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: I expect this is just a left-over and can be deleted? Here's a possible reason to leave this: users can get the history of this folder, and find older releases, where they might expect them. I'm no subversion expert, but I think since you moved uima-as in subversion, all the history is there and keeping this folder serves no purpose. This is true. It's more a question of the user-interface. If we keep this, then a user who remembers or has some reference here, will find this in SVN and can right click the folder (say with TortiseSVN installed) and have a look at the history. With it removed, the user has to experience some confusion - where did it go? - and then (maybe slowly - unless they're an SVN expert) realize that they could go to the containing folder, and ask for the history on that folder, and search for what happened to this one. At least, that's my imagination of what has to happen - but - perhaps there's even a better way? -Marshall I'm ok with removing it though, if that's the more normal, less confusing approach. -Marshall --Thilo
[jira] Reopened: (UIMA-1437) Fix UIMA AS testcase code to address intermittent hangs
[ https://issues.apache.org/jira/browse/UIMA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1437: - Modify Deploy_NoOpAnnotatorWithCpCException.xml to continue on CPC Error Fix UIMA AS testcase code to address intermittent hangs --- Key: UIMA-1437 URL: https://issues.apache.org/jira/browse/UIMA-1437 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik A recent fix that introduced a SharedConnection object exposed a threading problem in the testcase code. Testcases in the extended suite were not being completely cleaned up between runs. Some of the threads from a previous testcase were still running in a new testcase. Modify the testcase code to make sure that all threads are finished before starting another testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1459) Fix UIMA AS bugs reported by Findbugs
[ https://issues.apache.org/jira/browse/UIMA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1459. --- Resolution: Fixed Fixes NPE while trying to extract a queue name from uninitialized destination object in UimaDefaultMessageListenerContainer.afterPropertiesSet() Fix UIMA AS bugs reported by Findbugs - Key: UIMA-1459 URL: https://issues.apache.org/jira/browse/UIMA-1459 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Bhavani Iyer Fix For: 2.3AS Attachments: UIMA-1459.patch There are many bugs found by Findbugs in the UIMA As code. Some are minor like a deadstore in a var that is never used. Others are more severe like dereferencing a var that is not checked for NULL. Clean up the code to eliminate reported bugs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Still a uima-as directory in the sandbox
I would prefer to delete the directory. However, if we do want to keep it, how about adding a (very short) readme that directs people to the new location? An empty directory seems a bit confusing. --Thilo Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: I expect this is just a left-over and can be deleted? Here's a possible reason to leave this: users can get the history of this folder, and find older releases, where they might expect them. I'm no subversion expert, but I think since you moved uima-as in subversion, all the history is there and keeping this folder serves no purpose. This is true. It's more a question of the user-interface. If we keep this, then a user who remembers or has some reference here, will find this in SVN and can right click the folder (say with TortiseSVN installed) and have a look at the history. With it removed, the user has to experience some confusion - where did it go? - and then (maybe slowly - unless they're an SVN expert) realize that they could go to the containing folder, and ask for the history on that folder, and search for what happened to this one. At least, that's my imagination of what has to happen - but - perhaps there's even a better way? -Marshall I'm ok with removing it though, if that's the more normal, less confusing approach. -Marshall --Thilo
Re: svn commit: r808996 - /incubator/uima/uimaj/trunk/uimaj-bootstrap/
We have a very long list of jars in setUimaClassPath largely because we are uncertain how many ActiveMQ jars to include ... currently we specify only 14 of the 31 that AMQ loads. And one of ours is wrong as we specify commons-collections-3.1.jar while the library has commons-collections-2.1.jar ... which causes an apparently innocuous message that is usually suppressed: 8/28/09 3:49:54 PM - 0: org.springframework.util.ClassUtils.isPresent: FINE: Class [org.apache.commons.collections.map.LinkedMap] or one of its dependencies is not present: java.lang.ClassNotFoundException: org.apache.commons.collections.map.LinkedMap I was hoping that using a jar loader would avoid such mistakes, and also make it easier for users to switch ActiveMQ versions by merely renaming the parent directory. We could perhaps use AMQ's run.jar for these uima-as scripts and load everything that their scripts load. If there are some uima jars that should not be loaded perhaps they should be in an optional directory. -Burn
[jira] Created: (UIMA-1540) Uima AS client consumes too much CPU while waiting for a free CAS
Uima AS client consumes too much CPU while waiting for a free CAS -- Key: UIMA-1540 URL: https://issues.apache.org/jira/browse/UIMA-1540 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2AS Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Fix For: 2.3AS The UIMA AS client enters a busy loop in the getCAS() in BaseUIMAAsynchronousEngineCommon_impl. Since a CAS instance may not be available for awhile, this code wastes CPU cycles by continuously testing for null and trying again. Put the thread to sleep for some time before testing for CAS availability again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIMA AS client CPU load
Jorn, I've fixed this under UIMA-1540. Let me know if this fixes the
problem.
Thanks for pointing this out.
Jerry
On Tue, Sep 1, 2009 at 8:26 AM, Jörn Kottmann kottm...@gmail.com wrote:
Posted it a few days ago, would be nice if someone
could have a look. I assume there is a wait missing, right ?
If so the fix is simple and we can include it in 2.3.0.
Jörn
Jörn Kottmann wrote:
Hi everyone,
to put some load on one of our UIMA AS system I wrote
a small tool which uses the client API to send CASes to
a processing pipeline.
This tool has an endless loop which waits for work
to arrive and then sends it to the processing pipeline.
It basically looks like this:
text = getNextDocument() // returns plain text which should be analyzed
CAS cas = uimASEngine.getCAS();
cas.setDocumentText(text)
uimaAsEngine.sendCAS(cas)
When the tool is started there is usually lots of work waiting
and all available CASes are sent out to the service. It takes a while
until the first CAS is completly processed. Now the
tool gets a new text and waits for a new CAS inside getCAS().
Now I wonder why waiting for a CAS inside getCAS() puts 95 to 100 % CPU
load
on one core on my client machine.
I looked at the place where it waits in
BaseUIMAAsynchronousEngineCommon_impl
around line 536 in getCAS().
Here is the wait loop:
while (running) {
try {
// Wait until the CAS producer adds the CAS to the CasQueueEntry
and
// signals CAS availability.
entry.getSemaphore().acquire();
if (entry.getCas() == null) {
continue;
} else {
return entry.getCas();
}
} finally {
entry.getSemaphore().release();
} } // while
For me it looks like that if entry.getCAS() returns null it immediately
tries again and polls entry.getCAS() as often as possible.
Jörn
Re: svn commit: r808996 - /incubator/uima/uimaj/trunk/uimaj-bootstrap/
Burn Lewis wrote: We have a very long list of jars in setUimaClassPath largely because we are uncertain how many ActiveMQ jars to include ... currently we specify only 14 of the 31 that AMQ loads. And one of ours is wrong as we specify commons-collections-3.1.jar while the library has commons-collections-2.1.jar ... which causes an apparently innocuous message that is usually suppressed: 8/28/09 3:49:54 PM - 0: org.springframework.util.ClassUtils.isPresent: FINE: Class [org.apache.commons.collections.map.LinkedMap] or one of its dependencies is not present: java.lang.ClassNotFoundException: org.apache.commons.collections.map.LinkedMap I was hoping that using a jar loader would avoid such mistakes, and also make it easier for users to switch ActiveMQ versions by merely renaming the parent directory. We could perhaps use AMQ's run.jar for these uima-as scripts and load everything that their scripts load. If there are some uima jars that should not be loaded perhaps they should be in an optional directory. -Burn That's up to you of course. It has been my experience that manually maintaining your startup scripts may be painful, but it costs less time in the long run. Loads of fun when these sorts of problems crop up on a customer's machine that you don't have access to and you need to remote debug what the issue might be. It's a different story if this is just for yourself and you always have a developer next door who can help you out. --Thilo
[jira] Updated: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-629: Description: If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. was: If the original source file name is not present in the CAS, the XmiCasWriter names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. Summary: Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader (was: Default file names produced by XmiCasWriter don't have .xmi extension and can't be read by XmiCollectionReader) Correct the name of the component Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Still a uima-as directory in the sandbox
I also think we should delete the directory, because its moved (with history) to a new location, which can be easily found. The tagged versions remains in the sandbox, in case someone is looking for the old release version. Jörn
Re: UIMA AS client CPU load
Jaroslaw Cwiklik wrote: Jorn, I've fixed this under UIMA-1540. Let me know if this fixes the problem. Yeah, tried to build it, but it the tests hang here: +-- Sep 1, 2009 5:54:13 PM org.apache.uima.aae.controller.BaseAnalysisEngineController logPlatformInfo INFO: +-- Starting UIMA AS Service - PID:20891 +-- + Service Name:Person Title Annotator + Service Queue Name:PersonTitleAnnotatorQueue + Service Start Time:01 Sep 2009 17:54:05 + UIMA AS Version:2.3.0 + UIMA Core Version:2.3.0 + OS Name:Linux + OS Version:2.6.28-15-generic + OS Architecture:i386 + OS CPU Count:2 + JVM Vendor:Sun Microsystems Inc. + JVM Name:Java HotSpot(TM) Server VM + JVM Version:14.0-b16 + JVM Input Args:[-Xmx300M] + JVM Classpath:/usr/share/maven2/boot/classworlds.jar + JVM LIB_PATH:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386/server:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib +-- Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.JmsInputChannel setEndpointName INFO: top_level_input_queue_service_1 Service Starting - Listening for Messages Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.SpringContainerDeployer waitForServiceNotification INFO: Uima EE Client Blocking - Awaiting Top Level Controller Initialization Notification Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2000 OR Command=2002 Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2001 CasManager Initialized Cas Pool:PrimitiveAEService. Cas Pool Size:5 Initial Cas Heap Size:50 cells Service:Person Title Annotator Initialized. Ready To Process Messages From Queue:PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl initialize INFO: * Initialized the Controller. Person Title Annotator Ready To Process. Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl setupConnection INFO: UIMA AS Client Created Shared Connection To Broker: tcp://karkand:8118 UIMA AS Client Created Shared Connection To Broker:tcp://karkand:8118 Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeProducer INFO: Initializing JMS Message Producer. Broker: tcp://karkand:8118 Queue Name: PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeConsumer INFO: Initializing JMS Message Consumer. Broker: tcp://karkand:8118 Queue Name: ID:karkand-56803-1251820447466-3:2:1 Client Activated Temp Reply Queue:ID:karkand-56803-1251820447466-3:2:1 Sep 1, 2009 5:54:15 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initialize INFO: Asynchronous Client Has Been Initialized. Serialization Strategy: [xmi] Ready To Process. First Initialize Call Completed Received Expected Exception:class org.apache.uima.UIMA_IllegalStateException
Re: UIMA AS client CPU load
Jorn, I took Burn's suggestion and removed a busy loop from the getCas(). Instead of waiting between retries I use a semaphore to signal availability of a CAS. Not sure what this hang is all about. Can you refresh all projects from the svn and try again. Thanks On Tue, Sep 1, 2009 at 12:03 PM, Jörn Kottmann kottm...@gmail.com wrote: Jaroslaw Cwiklik wrote: Jorn, I've fixed this under UIMA-1540. Let me know if this fixes the problem. Yeah, tried to build it, but it the tests hang here: +-- Sep 1, 2009 5:54:13 PM org.apache.uima.aae.controller.BaseAnalysisEngineController logPlatformInfo INFO: +-- Starting UIMA AS Service - PID:20891 +-- + Service Name:Person Title Annotator + Service Queue Name:PersonTitleAnnotatorQueue + Service Start Time:01 Sep 2009 17:54:05 + UIMA AS Version:2.3.0 + UIMA Core Version:2.3.0 + OS Name:Linux + OS Version:2.6.28-15-generic + OS Architecture:i386 + OS CPU Count:2 + JVM Vendor:Sun Microsystems Inc. + JVM Name:Java HotSpot(TM) Server VM + JVM Version:14.0-b16 + JVM Input Args:[-Xmx300M] + JVM Classpath:/usr/share/maven2/boot/classworlds.jar + JVM LIB_PATH:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386/server:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib +-- Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.JmsInputChannel setEndpointName INFO: top_level_input_queue_service_1 Service Starting - Listening for Messages Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.SpringContainerDeployer waitForServiceNotification INFO: Uima EE Client Blocking - Awaiting Top Level Controller Initialization Notification Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2000 OR Command=2002 Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2001 CasManager Initialized Cas Pool:PrimitiveAEService. Cas Pool Size:5 Initial Cas Heap Size:50 cells Service:Person Title Annotator Initialized. Ready To Process Messages From Queue:PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl initialize INFO: * Initialized the Controller. Person Title Annotator Ready To Process. Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl setupConnection INFO: UIMA AS Client Created Shared Connection To Broker: tcp://karkand:8118 UIMA AS Client Created Shared Connection To Broker:tcp://karkand:8118 Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeProducer INFO: Initializing JMS Message Producer. Broker: tcp://karkand:8118 Queue Name: PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeConsumer INFO: Initializing JMS Message Consumer. Broker: tcp://karkand:8118 Queue Name: ID:karkand-56803-1251820447466-3:2:1 Client Activated Temp Reply Queue:ID:karkand-56803-1251820447466-3:2:1 Sep 1, 2009 5:54:15 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initialize INFO: Asynchronous Client Has Been Initialized. Serialization Strategy: [xmi] Ready To Process. First Initialize Call Completed Received Expected Exception:class org.apache.uima.UIMA_IllegalStateException
[jira] Commented: (UIMA-924) The UIMA AS service should notify the client via Status Listener if it is about to terminate due to excessive exceptions
[ https://issues.apache.org/jira/browse/UIMA-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749991#action_12749991 ] Jerry Cwiklik commented on UIMA-924: Low priority deferring to the next release The UIMA AS service should notify the client via Status Listener if it is about to terminate due to excessive exceptions Key: UIMA-924 URL: https://issues.apache.org/jira/browse/UIMA-924 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Priority: Minor When UIMA AS service is deployed from the AS Client it should use registered status listener callback to notify the client when the service is about to terminate due to excessive exceptions. It should report the last exception which caused the termination along with context which identies the state of processing (GetMeta, CPC or Process). This information may be usefull to the client application. Hold for later release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749998#action_12749998 ] Marshall Schor commented on UIMA-629: - This is a 1-line fix, but may break existing uses of this component, because it will change the generated name to have the suffix, in this defaulting case. Is that OK? Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-799) C++ service reconnect to JMS provider
[ https://issues.apache.org/jira/browse/UIMA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer reassigned UIMA-799: - Assignee: Bhavani Iyer C++ service reconnect to JMS provider - Key: UIMA-799 URL: https://issues.apache.org/jira/browse/UIMA-799 Project: UIMA Issue Type: Bug Components: C++ Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer The service wrapper currently fails when connection to the JMS provider is broken. It should attempt to reestablish the 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-799) C++ service reconnect to JMS provider
[ https://issues.apache.org/jira/browse/UIMA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-799: -- Attachment: UIMACPP-799.patch The modifications to the service wrapper to support reconnect include: 1. Replace registering a MessageListener to receive message with the synchrounous receive() api. 2. Added reporting of Reconnecting and ReconnectionSuccess status. 3. Added support for fast GetMeta. 4. Cleanup of code to support other JMS providers. 5. Cleaup to the JMX statistics C++ service reconnect to JMS provider - Key: UIMA-799 URL: https://issues.apache.org/jira/browse/UIMA-799 Project: UIMA Issue Type: Bug Components: C++ Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMACPP-799.patch The service wrapper currently fails when connection to the JMS provider is broken. It should attempt to reestablish the connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750048#action_12750048 ] Thilo Goetz commented on UIMA-629: -- +1 for going ahead with the fix. Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1326) Remove EMF dependency from uimaj-ep-runtime plugin
[ https://issues.apache.org/jira/browse/UIMA-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750062#action_12750062 ] Marshall Schor commented on UIMA-1326: -- This current approach has the following issues: * it essentially requires Eclipse. I think our intent with ecore did not include making it Eclipse - specific * It has special treatment to isolate source files outside of the normal source path, and special readme's to have the user include these in the source path, after they add ecore support jars from Eclipse, which they would have to obtain somehow. A simpler approach would be to * have no special treatment for the ecore examples * ship (distribute) the needed ecore jars with the examples, in a /lib directory This would allow stand-alone running of the ecore examples without Eclipse being installed or available. The Jars in question are * org/eclipse/emf/common-2.1.0.jar (134KB) * org/eclipse/emf/ecore-2.1.0.jar (625 KB) * org/eclipse/emf/ecore-xmi-2.1.0.jar (142KB) These we can distribute in binary form only under category b license terms - we have to include things in the NOTICE/LICENSE files for this. (Note that the maven build already gets these Jars from the maven repos and mvn eclipse:eclipse on the uimaj-examples project puts these jars into the generated classpath.) Should we change things to this simpler approach but which requires us to ship the 3 ecore support Jars, or leave things the way they are? I'm on the fence... in favor of simplicity, but not wanting to grow our bin distribution by 900KB. Other opinions? Remove EMF dependency from uimaj-ep-runtime plugin -- Key: UIMA-1326 URL: https://issues.apache.org/jira/browse/UIMA-1326 Project: UIMA Issue Type: Improvement Components: Eclipse plugins Affects Versions: 2.3 Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 Attachments: uima-as-distr_1326.patch, uimaj-distr_1326.patch, uimaj-examples_1326.patch The uimaj-ep-runtime plugin depends on EMF, this dependency makes deploying in an non eclipse OSGI environment difficult since EMF depends on org.eclipse.core.runtime, which depends on many other eclipse plugins. Since EMF is only really used in the examples project, the dependency is removed from uimaj-core and the classes Ecore2UimaTypeSystem and UimaTypeSystem2Ecore.java are moved to uimaj-examples. The uimaj-ep-runtime plugin contains currently uimaj-examples, that could be moved to a seperate plugin or shipped with an OSGI bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-554) Have produceResource for CollectionReaders operate like other Analysis Engines with respect to setup of type system
[ https://issues.apache.org/jira/browse/UIMA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-554. --- Resolution: Fixed Fix Version/s: 2.3 We expect this fix to be backwards compatible. Adding metadata twice does no harm, as all the metadata is merged at some point anyways. Have produceResource for CollectionReaders operate like other Analysis Engines with respect to setup of type system --- Key: UIMA-554 URL: https://issues.apache.org/jira/browse/UIMA-554 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.1, 2.2 Reporter: Marshall Schor Priority: Trivial Fix For: 2.3 This code fails but works if you uncomment out line 3: CollectionReader cr = UIMAFramework.produceCollectionReader(aSpecifier); CasManager casManager = cr.getCasManager(); // casManager.addMetaData((ProcessingResourceMetaData)cr.getMetaData()); casManager.defineCasPool(pool, 2, null); Other produce methods (i.e. for analysis engines) add their metadata to their cas managers. Consider doing this for Collection Readers too (this is now done during CPE initialization). Use case: User found this while trying to test collection reader by itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1280) Missing message key in CPM at FINEST logging
[ https://issues.apache.org/jira/browse/UIMA-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1280. --- Resolution: Fixed Defined key UIMA_CPM_pipeline_exception__FINEST in the cpm message properties file 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] Resolved: (UIMA-1114) DocumentAnalyzer: html view doesn't work for aggregates
[ https://issues.apache.org/jira/browse/UIMA-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor resolved UIMA-1114. -- Resolution: Fixed Assignee: Thilo Goetz Found that the html viewer didn't work at all - got a cannot compile transform error. Changed an xsl template, and now appears to work. Please test further and reopen if you can get it to fail. DocumentAnalyzer: html view doesn't work for aggregates --- Key: UIMA-1114 URL: https://issues.apache.org/jira/browse/UIMA-1114 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.2.2 Reporter: Thilo Goetz Assignee: Thilo Goetz Priority: Minor Fix For: 2.3 To reproduce, use the sandbox Tagger aggregate. You need to add output capabilities for the DocumentAnalyzer to show any results (is this documented?). Then you see annotations in the java viewer, but not in html. In Firefox 2, there's also a Javascript error. There's no error in IE 6, but still no annotations are displayed :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1524) JFSIndexRepository should be enhanced with new generic methods
[ https://issues.apache.org/jira/browse/UIMA-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1524: - Affects Version/s: 2.3 Fix Version/s: (was: 2.3) Defer past 2.3.0. There are several changes / augmentations that can be done to exploit Java 5. One issue is how best to do them, given that our interfaces for many parts of UIMA are fixed - and cannot have additional methods added without breaking compatibility. JFSIndexRepository should be enhanced with new generic methods -- Key: UIMA-1524 URL: https://issues.apache.org/jira/browse/UIMA-1524 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.3 Reporter: Jörn Kottmann Existing methods should be overloaded with an additional Class argument to specify the exact return type. This changes make down casting of returned objects unnecessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750168#action_12750168 ] Adam Lally commented on UIMA-629: - +1 Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-4) Set svn:eol-style and other flags on appropriate files
[ https://issues.apache.org/jira/browse/UIMA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-4. - Resolution: Fixed Set svn:eol-style and other flags on appropriate files -- Key: UIMA-4 URL: https://issues.apache.org/jira/browse/UIMA-4 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Marshall Schor Priority: Minor Construct an appropriate shell script, and run it to check the eol-style and keyword and mime-type for files in SVN. For test files, check that eol-style is LF. For normal sources, check eol-style is native. Suggest we have an apache-tools project (under top level, no need for branches / tags?) to hold these kinds of support tools - or is there a better place for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
