Re: Issues not closed for 2.3.0 release

2009-10-20 Thread Thilo Goetz
Marshall Schor wrote:
[...]
 Both of these approaches put uimaj-core classes at the root level of
 the application (i.e., System) class-loader chain.  I can't think of
 any cases where that would not be OK; can anyone else?

I think that may not work because the UIMA
framework classes need to access the annotator classes.
If the core is loaded by the system classloader, it
will not have access to classes loaded by the bs loader.

--Thilo



UIMA-AS error handling in case an exception is thrown from CM.next method

2009-10-20 Thread Jörn Kottmann

Hi everyone,

I might found a problem in the error handling when
an exception is thrown from the CasMultiplier.next method
before getEmptyCas was called.

UIMA-AS prints out the stack trace of the exception from the next method
and afterwards it prints out the following exception stack trace, is 
that expected

behavior ?

Jörn

Here is the exception stack trace:
CASAdminException: Can't flush CAS, flushing is disabled.
   at org.apache.uima.cas.impl.CASImpl.reset(CASImpl.java:869)
   at org.apache.uima.util.CasPool.releaseCas(CasPool.java:224)
   at 
org.apache.uima.resource.impl.CasManager_impl.releaseCas(CasManager_impl.java:141)
   at 
org.apache.uima.cas.AbstractCas_ImplBase.release(AbstractCas_ImplBase.java:35)

   at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3591)
   at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3589)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1040)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1273)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.dropCAS(AggregateAnalysisEngineController_impl.java:302)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.sendReplyToRemoteClient(AggregateAnalysisEngineController_impl.java:1832)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.replyToClient(AggregateAnalysisEngineController_impl.java:1943)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1567)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.abortProcessingCas(AggregateAnalysisEngineController_impl.java:971)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.process(AggregateAnalysisEngineController_impl.java:1010)
   at 
org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError(ProcessCasErrorHandler.java:521)
   at 
org.apache.uima.aae.error.ErrorHandlerChain.handle(ErrorHandlerChain.java:57)
   at 
org.apache.uima.aae.handler.input.ProcessResponseHandler.handleProcessResponseWithException(ProcessResponseHandler.java:535)
   at 
org.apache.uima.aae.handler.input.ProcessResponseHandler.handle(ProcessResponseHandler.java:642)
   at 
org.apache.uima.aae.handler.HandlerBase.delegate(HandlerBase.java:149)
   at 
org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handle(ProcessRequestHandler_impl.java:951)
   at 
org.apache.uima.aae.spi.transport.vm.UimaVmMessageListener.onMessage(UimaVmMessageListener.java:107)
   at 
org.apache.uima.aae.spi.transport.vm.UimaVmMessageDispatcher$1.run(UimaVmMessageDispatcher.java:70)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

   at java.lang.Thread.run(Thread.java:619)
CASAdminException: Can't flush CAS, flushing is disabled.
   at org.apache.uima.cas.impl.CASImpl.reset(CASImpl.java:869)
   at org.apache.uima.util.CasPool.releaseCas(CasPool.java:224)
   at 
org.apache.uima.resource.impl.CasManager_impl.releaseCas(CasManager_impl.java:141)
   at 
org.apache.uima.cas.AbstractCas_ImplBase.release(AbstractCas_ImplBase.java:35)

   at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3591)
   at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3589)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1040)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1273)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.dropCAS(AggregateAnalysisEngineController_impl.java:302)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.sendReplyToRemoteClient(AggregateAnalysisEngineController_impl.java:1832)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.replyToClient(AggregateAnalysisEngineController_impl.java:1943)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1567)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.abortProcessingCas(AggregateAnalysisEngineController_impl.java:971)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.process(AggregateAnalysisEngineController_impl.java:1010)
   at 
org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError(ProcessCasErrorHandler.java:521)
   at 
org.apache.uima.aae.error.ErrorHandlerChain.handle(ErrorHandlerChain.java:57)
   at 
org.apache.uima.aae.handler.input.ProcessResponseHandler.handleProcessResponseWithException(ProcessResponseHandler.java:535)
   at 
org.apache.uima.aae.handler.input.ProcessResponseHandler.handle(ProcessResponseHandler.java:642)
   at 

[jira] Closed: (UIMA-1624) Uima AS service should start listeners on its input queue on succesfull initialization only

2009-10-20 Thread Jerry Cwiklik (JIRA)

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

Jerry Cwiklik closed UIMA-1624.
---

Resolution: Fixed

Changed uima-as code to delay startup of listeners on input queues until 
service initializes.  

 Uima AS service should start listeners on its input queue on succesfull 
 initialization only
 ---

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


 Currently UIMA AS service JMS listener starts as soon as it is initialized. 
 There are two listeners started on an input queue each with a different 
 selector. One listener is for processing GetMeta while the other for Process 
 messages. The listeners start in separate threads and become active despite 
 the fact that the rest of service components may not have finished 
 initializing. This creates a problem if the service fails in annotator code 
 while initializing. Since the GetMeta listener is active, it may fetch 
 GetMeta request from a queue and try to process it. The current code prevents 
 the GetMeta from being processed since the service has not finished 
 initializing. If the AE initialization fails, the getMeta is never returned 
 to the client. Fix input queue listeners so that they become active only 
 after successful initialization
 of AEs. In case of aggregates, allow listeners on temp reply queues to start 
 immediately so that GetMeta replies from delegates can be processed.

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



BaseAnalysisEngineController line 1742 IndexOutOfBoundsException

2009-10-20 Thread Jörn Kottmann

Hi,

I got an IndexOutOfBoundsException, I think there is
a concurrency problem at the mentioned place.

Jörn

Here is the stack trace:
Caused by: java.lang.IndexOutOfBoundsException: Index: 2, Size: 0
   at java.util.ArrayList.RangeCheck(ArrayList.java:547)
   at java.util.ArrayList.get(ArrayList.java:322)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.stop(BaseAnalysisEngineController.java:1741)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.stop(BaseAnalysisEngineController.java:1707)
   at 
org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.stop(AggregateAnalysisEngineController_impl.java:2753)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.terminate(BaseAnalysisEngineController.java:1967)
   at 
org.apache.uima.aae.controller.BaseAnalysisEngineController.terminate(BaseAnalysisEngineController.java:1940)
   at 
org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.initializeContainer(SpringContainerDeployer.java:313)
   at 
org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:390)

   ... 7 more



[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections

2009-10-20 Thread Jerry Cwiklik (JIRA)

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

Jerry Cwiklik reopened UIMA-1433:
-


UIMA AS service is not recovering properly when the broker is stopped and 
restarted. When the broker is bounced the service should invalidate its 
connection cache and create a new one. It should also invalidate all sessions 
and producers associated with a stale connection. The aggregate service with 
remote delegates will appear hung if the broker is bounced.

 UIMA AS service creates too many JMS connections 
 -

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


 UIMA AS service maintains connections to client's reply queue. These 
 connections are cached and reused. When the connection becomes idle for too 
 long, it is closed. Current default connection timeout is set to 30 minutes. 
 This value can be changed via System property -DSessionTimeoutOverride=n.
 JMS Connections are expensive, and if too many are created the broker may 
 become unstable. As optimization, the service should create a single JMS 
 connection (per broker) and use it to create jms sessions and message 
 producers for each client. This change will  reduce number of threads the 
 broker needs to manage in deployments where clients and services use a single 
 broker for messaging.  

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



[jira] Created: (UIMA-1627) Application link not working on gcc 4.2

2009-10-20 Thread Eddie Epstein (JIRA)
Application link not working on gcc 4.2
---

 Key: UIMA-1627
 URL: https://issues.apache.org/jira/browse/UIMA-1627
 Project: UIMA
  Issue Type: Bug
  Components: C++ Framework
Reporter: Eddie Epstein
Assignee: Eddie Epstein


Need to explicitly specify -lapr-1

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



Re: Issues not closed for 2.3.0 release

2009-10-20 Thread Marshall Schor


Thilo Goetz wrote:
 Marshall Schor wrote:
 [...]
   
 Both of these approaches put uimaj-core classes at the root level of
 the application (i.e., System) class-loader chain.  I can't think of
 any cases where that would not be OK; can anyone else?
 

 I think that may not work because the UIMA
 framework classes need to access the annotator classes.
 If the core is loaded by the system classloader, it
 will not have access to classes loaded by the bs loader.
   
Yes, this sounds right.

How about this fix: put a copy of the UIMALogFormatter into the
bootstrap loader Jar.  This class does not reference any uima classes,
only Java JRE classes.

-Marshall

 --Thilo



   


Re: Issues not closed for 2.3.0 release

2009-10-20 Thread Marshall Schor


Marshall Schor wrote:
 Thilo Goetz wrote:
   
 Marshall Schor wrote:
 [...]
   
 
 Both of these approaches put uimaj-core classes at the root level of
 the application (i.e., System) class-loader chain.  I can't think of
 any cases where that would not be OK; can anyone else?
 
   
 I think that may not work because the UIMA
 framework classes need to access the annotator classes.
 If the core is loaded by the system classloader, it
 will not have access to classes loaded by the bs loader.
   
 
 Yes, this sounds right.

 How about this fix: put a copy of the UIMALogFormatter into the
 bootstrap loader Jar.  This class does not reference any uima classes,
 only Java JRE classes.
   
I think this issue is general, not restricted to the Formatter class. 
The Javadocs for the LogManager say that the class objects named in the
configuration are loaded by using the System class loader.  It actually
says the classes are first searched on the system class path before any
user class path.   But it seems that only the application initial class
path that is used to launch things, is searched.

So maybe the only approach will be to inject all the urls into the
system class loader, as Jerry was trying to do (Jars and directories,
not individual classes). 

Any other ideas?

-Marshall
 -Marshall

   
 --Thilo